Desarrollo de workflow para Continuous Training utilizando CML

name: Continuous Training
on:
  push:
    branches:
      - workflow_continuous_training
  # Para que github action corra el worflow con este crontab, es decir cada 6 horas
  schedule:
    - cron: '0 */6 * * *'
  # Por si queremos correrlo manualmente
  workflow_dispatch:
    inputs:
      reason:
        description: Why to run this?
        required: false
        default: running CT
# These permissions are needed to interact with GitHub's OIDC Token endpoint.
permissions:
  id-token: write # need this for OIDC  
  contents: write
  pull-requests: write 
  issues: read
  packages: none
jobs:
  continuous-training:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repo
        uses: actions/checkout@v3
      - name: Set AWS credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          role-session-name: aws_testing_session
          role-to-assume: ${{ secrets.AWS_IAM_ROLE }}
          aws-region: ${{ secrets.AWS_REGION }}
      - name: Train model
        run: |
          pip install pipenv
          pipenv install
          pipenv run python
          pip install -r src/requirements.txt
          dvc pull model/model.pkl.dvc -r model-tracker
          dvc unprotect model/model.pkl
          dvc repro -f 
          echo "Training Completed"
          dvc add model/model.pkl
          dvc push model/model.pkl -r model-track
        # Running dvc unprotect guarantees that the target files or directories (targets) in the workspace are physically “unlinked” from the cache and can be safely updated. 
      - name: Commit .dvc file changes
        run: |
          git config --local user.email "[email protected]"
          git config --local user.name "github-actions[bot]"
          git add model/model.pkl.dvc
          git commit -m "Updating model serialization"
      - uses: ad-m/github-push-action@master
        with:
            github_token: ${{ secrets.GITHUB_TOKEN }}
            branch: ${{ github.ref }}
      - uses: iterative/setup-cml@v1
      - name: Push metrics
        env:
          REPO_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          cat report.txt >> report.md 
          cml-publish prediction_behavior.png --md >> report.md
          cml-send-comment report.md

El error que les aparece a algunas personas es por la version de Node. Lanza un error de 400 Bad request que solo interfiere con el intento de agregar la imagen (mas no el texto de report.txt).

Actualmente GitHub Actions usa la version 12 por defecto, a partir del 27 de Setiembre usará la 16 (como nuevo default) https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/

Para definir las directivas de Node en el archivo yaml, se ubica dentro de steps, llamalo cerca al inicio, ya sea antes o despues de cargar el repo:

      - name: Set up Node 16
        uses: actions/setup-node@v1
        with:
          node-version: '16'

En el caso de pipevash encontré su usuario de github y le actualicé eso con un pull request.

AzureML tiene también un muy buen pipeline de reentrenamiento

Triggers AzureML

Éste error me dio muchos problemas

|
*
|
Lo solucioné comentando estas lineas de código

 # - uses: ad-m/github-push-action@master
      #   with:
      #       github_token: ${{ secrets.GITHUB_TOKEN }}
      #       branch: ${{ github.ref }}
      - uses: iterative/setup-cml@v1
      - name: Push metrics
        env:
          REPO_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          cat report.txt >> report.md 
          cml-publish prediction_behavior.png --md >> report.md
          cml-send-comment report.md

Parece que tenia conflictos al llamar dos veces la GITHUB_TOKEN
|
*
|

Dejo mi resultado
|

encontré muy interesante esto, pero realmente tengo aun que probarlo. La idea es que se puedan probar las Github actions de manera local, antes de hacer los commits y los push, de manera que el timeline no se llene de commits de fixes; además porque al correr de manera local puede que el proceso sea más rápido si se cuenta con una buena máquina y los contenedores quedan guardados.
En mi caso, Github actions se demora mucho, al rededor de 7 minutos para cada prueba.

Hay un pequeño error en el worflow, casi imperceptible ya que no afecta, pero igualmente un error en si.

El primero es agregar a dvc con:

          dvc add model/model.pkl
          dvc push model/model.pkl -r model-track

Para seguir la buena practica que comentaron otros ccompañeros en clases anteriores para no tener problema el md5.

Y un error en el workflows que si es del profesor:

          dvc add model/model.pkl -r model-tracker --to-remote
          dvc push model/model.pkl.dvc -r model-tracker

A dvc para que vamos a enviar el archivo model.pkl.dvc, si la gracia de este archivo es que este en github, y el archivo model.pkl y .csv que pueden pesar mas, esten alojados en nuestro servidor manejados por dvc,

No se notara el error ya que previamente durante la creacion del proyecto ya tenemos en el servidor nuestro model.pkl, entonces cuando lo necesitemos vamos a usar, pero model.pkl.dvc, por muy bonito que sea que este subido al servicio de almacenamiento de su preferencia, no hara nada.

Igual este error se nota posteriormente con la siguiente linea:

 git add model/model.pkl.dvc

Subimos a dvc y a git el mismo archivo.

Tuve problemas con la parte en que el flujo trata de hacer el commit de los cambios al repositorio git commit -m "Updating model tracked", porque me decía que no tenía permisos.
Para resolverlos, fui a la rama en Github, luego a Settings. En el menú a la izquierda seleccioné Actions, y del desplegable General. en la sección Workflow permissions, seleccione Read and write permissions. Y le di guardar. Con eso ya se podían hacer commits.

en caso de tener este error en el paso de al intalar librerias:

AttributeError: module 'lib' has no attribute 'X509_V_FLAG_CB_ISSUER_CHECK'

actualicen esta libreria pyOpenSLL y listo,

- name: Installing dependencies
        run: |
          pip3 install pyOpenSSL --upgrade
          pip install dvc[gs]
          pip install -r test/requirements_test.txt

Creo que es peligroso hacer ese tipo de commits a producción sin correr tests previamente. Debería haber una advertencia de los problemas asociados a este workflow:

• puedes subir a DVC archivos innecesarios
• puedes subir modelos rotos a producción o a tu nube con dvc (en el caso de que este workflow pase pero el testing de la api no lo haga)

Hay una nueva version de dvc > 3.0 , recuerden urtilizar la misma version cuando hicieron el seguimiento local y el que se hace en el workflow.