GitHub Actions

info

Aperçu

Cette fonctionnalité est en aperçu public.

GitHub Actions déclenchent les exécutions de vos flux CI/CD à partir de vos repositories GitHub et vous permettent d'automatiser votre pipeline CI/CD de build, de test et de déploiement.

Cette page fournit des informations concernant les GitHub Actions développées par Databricks et des exemples pour des cas d'utilisation courants. Pour plus d'informations sur les autres fonctionnalités et les meilleures pratiques CI/CD sur Databricks, consultez les éléments suivants :

• CI/CD sur Databricks
• Workflows CI/CD sur Databricks
• Bonnes pratiques de développement sur Databricks

Databricks GitHub Actions

Databricks a développé les GitHub Actions suivants pour vos workflows CI/CD sur GitHub. Ajoutez les fichiers YAML de GitHub Actions au répertoire .github/workflows de votre dépôt.

remarque

Cet article couvre GitHub Actions, qui est développé par un tiers. Pour contacter le fournisseur, voir GitHub Actions Support.

GitHub Actions	Description
databricks/setup-cli	Une action composite qui configure le CLI Databricks dans un workflow GitHub Actions.

GitHub Actions	Description
databricks/setup-cli	Une action composite qui configure le CLI Databricks dans un workflow GitHub Actions.

Exécuter un workflow CI/CD qui met à jour un dossier Git

L'exemple de fichier YAML GitHub Actions suivant met à jour un dossier Git de workspace lorsqu'une branch distante est mise à jour. Pour plus d'informations sur l'approche de dossier Git pour le CI/CD, consultez Autres outils de contrôle de code source.

Exigences

Cet exemple utilise la fédération d'identité de charge de travail pour GitHub Actions pour une sécurité améliorée, et nécessite que vous ayez ajouté un Service Principal dans votre compte avec une politique de fédération GitHub Actions. Consultez Activer la fédération d'identité de charge de travail pour GitHub Actions.

important

Le sujet de la politique de fédération (l'identité du jeton fédéré) doit correspondre exactement au sujet de jeton attendu. Pour cet exemple, le type et le nom de l'entité sont Environment et Prod . L'objet construit doit être sous la forme repo:my-github-org-or-user/my-repo:environment:Prod.

Après avoir créé un Service Principal avec une politique de fédération, définissez la variable d'environnement DATABRICKS_HOST sur votre Workspace hôte Databricks et la variable d'environnement DATABRICKS_CLIENT_ID sur l'UUID du Service Principal. La variable d'environnement DATABRICKS_AUTH_TYPE est définie dans l'action. Pour plus d'informations sur les variables d'environnement Databricks, consultez Variables d'environnement et champs pour l'authentification unifiée.

Créer l'Action

Maintenant, ajoutez un fichier .github/workflows/sync_git_folder.yml à votre repository avec le YAML suivant :

YAML

name: Sync Git Folder

concurrency: prod_environment

on:
  push:
    branches:
      # Set your base branch name here
      - git-folder-cicd-example

permissions:
  # These permissions are required for workload identity federation.
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    name: 'Update git folder'
    environment: Prod
    env:
      DATABRICKS_AUTH_TYPE: github-oidc
      DATABRICKS_HOST: ${{ vars.DATABRICKS_HOST }}
      DATABRICKS_CLIENT_ID: ${{ secrets.DATABRICKS_CLIENT_ID }} # This is the service principal UUID.

    steps:
      - uses: actions/checkout@v3
      - uses: databricks/setup-cli@main
      - name: Update git folder
        # Set your workspace path and branch name here
        run: databricks repos update /Workspace/<git-folder-path> --branch git-folder-cicd-example

Exécuter un workflow CI/CD avec un bundle qui exécute une mise à jour de pipeline

Le fichier YAML GitHub Actions d'exemple suivant Trigger un déploiement de test qui valide, déploie et exécute le job spécifié dans le bundle au sein d'une cible de pré-production nommée dev telle que définie dans un fichier de configuration de bundle.

Exigences

Cet exemple requiert qu'il y ait :

• Une variable d'environnement définie par l'utilisateur DATABRICKS_BUNDLE_ENV.

• Un fichier de configuration de bundle à la racine du repository, qui est explicitement déclaré via le paramètre working-directory: . du fichier YAML de GitHub Actions. Ce fichier de configuration de bundle doit définir un workflow Databricks nommé sample_job et une cible nommée dev. Par exemple :

  YAML

  # This is a bundle definition for pipeline_update.
  bundle:
    name: pipeline_update
  
  include:
    - resources/*.yml
  
  variables:
    catalog:
      description: The catalog to use
    schema:
      description: The schema to use
  
  resources:
    jobs:
      sample_job:
        name: sample_job
  
        parameters:
          - name: catalog
            default: ${var.catalog}
          - name: schema
            default: ${var.schema}
  
        tasks:
          - task_key: refresh_pipeline
            pipeline_task:
              pipeline_id: ${resources.pipelines.sample_pipeline.id}
  
        environments:
          - environment_key: default
            spec:
              environment_version: '4'
  
    pipelines:
      sample_pipeline:
        name: sample_pipeline
        catalog: ${var.catalog}
        schema: ${var.schema}
        serverless: true
        root_path: '../src/sample_pipeline'
  
        libraries:
          - glob:
              include: ../src/sample_pipeline/transformations/**
  
        environment:
          dependencies:
            - --editable ${workspace.file_path}
  
  targets:
    dev:
      mode: development
      default: true
      workspace:
        host: <dev-workspace-url>
      variables:
        catalog: my_catalog
        schema: ${workspace.current_user.short_name}
    prod:
      mode: production
      workspace:
        host: <production-workspace-url>
        root_path: /Workspace/Users/someone@example.com/.bundle/${bundle.name}/${bundle.target}
      variables:
        catalog: my_catalog
        schema: prod
      permissions:
        - user_name: someone@example.com
          level: CAN_MANAGE

  Pour plus d'informations sur la configuration des bundles, consultez la configuration des Declarative Automation Bundles.

• Un secret GitHub nommé SP_TOKEN, représentant le jeton d'accès Databricks pour un Service Principal Databricks qui est associé à l'espace de travail Databricks sur lequel ce bundle est déployé et exécuté. Pour créer un jeton :

  1. Créer un Service Principal Databricks. Consultez Ajouter des services principaux à votre compte.
  2. Générez un secret pour le service principal. Consultez Étape 1 : Créer un secret OAuth. Copiez les valeurs de l'ID client et du secret.
  3. Générez manuellement un jeton d'accès Databricks (compte ou workspace) à l'aide des valeurs de secret et d'ID client copiées. Voir Générer un jeton d'accès au niveau du compte.
  4. Copiez la valeur access_token de la réponse JSON. Ajoutez un secret GitHub nommé SP_TOKEN aux Actions de votre repository et utilisez le jeton d'accès Databricks comme valeur secrète. Consultez Secrets chiffrés.

  La variable d'environnement d'authentification unifiée DATABRICKS_TOKEN est définie dans l'action sur le SP_TOKEN que vous avez configuré.

Créer l'Action

Maintenant, ajoutez un fichier .github/workflows/pipeline_update.yml à votre repository avec le YAML suivant :

YAML

# This workflow validates, deploys, and runs the specified bundle
# within a pre-production target named "dev".
name: 'Dev deployment'

# Ensure that only a single job or workflow using the same concurrency group
# runs at a time.
concurrency: 1

# Trigger this workflow whenever a pull request is opened against the repo's
# main branch or an existing pull request's head branch is updated.
on:
  pull_request:
    types:
      - opened
      - synchronize
    branches:
      - main

jobs:
  # Used by the "pipeline_update" job to deploy the bundle.
  # Bundle validation is automatically performed as part of this deployment.
  # If validation fails, this workflow fails.
  deploy:
    name: 'Deploy bundle'
    runs-on: ubuntu-latest

    steps:
      # Check out this repo, so that this workflow can access it.
      - uses: actions/checkout@v3

      # Download the Databricks CLI.
      # See https://github.com/databricks/setup-cli
      - uses: databricks/setup-cli@main

      # Deploy the bundle to the "dev" target as defined
      # in the bundle's settings file.
      - run: databricks bundle deploy
        working-directory: .
        env:
          DATABRICKS_TOKEN: ${{ secrets.SP_TOKEN }}
          DATABRICKS_BUNDLE_ENV: dev

  # Validate, deploy, and then run the bundle.
  pipeline_update:
    name: 'Run pipeline update'
    runs-on: ubuntu-latest

    # Run the "deploy" job first.
    needs:
      - deploy

    steps:
      # Check out this repo, so that this workflow can access it.
      - uses: actions/checkout@v3

      # Use the downloaded Databricks CLI.
      - uses: databricks/setup-cli@main

      # Run the Databricks workflow named "sample_job" as defined in the
      # bundle that was just deployed.
      - run: databricks bundle run sample_job --refresh-all
        working-directory: .
        env:
          DATABRICKS_TOKEN: ${{ secrets.SP_TOKEN }}
          DATABRICKS_BUNDLE_ENV: dev

Vous pourriez également souhaiter Trigger des déploiements en production. Le fichier YAML GitHub Actions suivant peut exister dans le même repository que le fichier précédent. Ce fichier valide, déploie et exécute le bundle spécifié au sein d'une cible de production nommée « prod », telle que définie dans un fichier de configuration de bundle.

YAML

# This workflow validates, deploys, and runs the specified bundle
# within a production target named "prod".
name: 'Production deployment'

# Ensure that only a single job or workflow using the same concurrency group
# runs at a time.
concurrency: 1

# Trigger this workflow whenever a pull request is pushed to the repo's
# main branch.
on:
  push:
    branches:
      - main

jobs:
  deploy:
    name: 'Deploy bundle'
    runs-on: ubuntu-latest

    steps:
      # Check out this repo, so that this workflow can access it.
      - uses: actions/checkout@v3

      # Download the Databricks CLI.
      # See https://github.com/databricks/setup-cli
      - uses: databricks/setup-cli@main

      # Deploy the bundle to the "prod" target as defined
      # in the bundle's settings file.
      - run: databricks bundle deploy
        working-directory: .
        env:
          DATABRICKS_TOKEN: ${{ secrets.SP_TOKEN }}
          DATABRICKS_BUNDLE_ENV: prod

  # Validate, deploy, and then run the bundle.
  pipeline_update:
    name: 'Run pipeline update'
    runs-on: ubuntu-latest

    # Run the "deploy" job first.
    needs:
      - deploy

    steps:
      # Check out this repo, so that this workflow can access it.
      - uses: actions/checkout@v3

      # Use the downloaded Databricks CLI.
      - uses: databricks/setup-cli@main

      # Run the Databricks workflow named "sample_job" as defined in the
      # bundle that was just deployed.
      - run: databricks bundle run sample_job --refresh-all
        working-directory: .
        env:
          DATABRICKS_TOKEN: ${{ secrets.SP_TOKEN }}
          DATABRICKS_BUNDLE_ENV: prod

Exécutez un workflow CI/CD qui crée un JAR et déploie un bundle.

Si vous disposez d'un écosystème basé sur Java, votre GitHub Action doit créer et upload un JAR avant de déployer le bundle. L'exemple de fichier YAML GitHub Actions suivant déclenche un déploiement qui crée et upload un JAR vers un volume, puis valide et déploie le bundle vers une cible de production nommée "prod", telle que définie dans le fichier de configuration du bundle. Il compile un JAR basé sur Java, mais les étapes de compilation pour un projet basé sur Scala sont similaires.

Exigences

Cet exemple requiert qu'il y ait :

• Un fichier de configuration de bundle à la racine du repository, qui est explicitement déclaré via le paramètre du fichier YAML de GitHub Actions working-directory: .
• Une variable d'environnement DATABRICKS_TOKEN qui représente le jeton d'accès Databricks associé au workspace Databricks où ce bundle est déployé et exécuté.
• Une variable d'environnement DATABRICKS_HOST qui représente le workspace hôte Databricks.

Créer l'Action

Maintenant, ajoutez un fichier .github/workflows/build_jar.yml à votre repository avec le YAML suivant :

YAML

name: Build JAR and deploy with bundles

on:
  pull_request:
    branches:
      - main
  push:
    branches:
      - main

jobs:
  build-test-upload:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Java
        uses: actions/setup-java@v4
        with:
          java-version: '17' # Specify the Java version used by your project
          distribution: 'temurin' # Use a reliable JDK distribution

      - name: Cache Maven dependencies
        uses: actions/cache@v4
        with:
          path: ~/.m2/repository
          key: ${{ runner.os }}-maven-${{ hashFiles('**/pom.xml') }}
          restore-keys: |
            ${{ runner.os }}-maven-

      - name: Build and test JAR with Maven
        run: mvn clean verify # Use verify to ensure tests are run

      - name: Databricks CLI Setup
        uses: databricks/setup-cli@v0.9.0 # Pin to a specific version

      - name: Upload JAR to a volume
        env:
          DATABRICKS_TOKEN: ${{ secrets.DATABRICKS_TOKEN }}
          DATABRICKS_HOST: ${{ secrets.DATABRICKS_HOST }} # Add host for clarity
        run: |
          databricks fs cp target/my-app-1.0.jar dbfs:/Volumes/artifacts/my-app-${{ github.sha }}.jar --overwrite

  validate:
    needs: build-test-upload
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Databricks CLI Setup
        uses: databricks/setup-cli@v0.9.0

      - name: Validate bundle
        env:
          DATABRICKS_TOKEN: ${{ secrets.DATABRICKS_TOKEN }}
          DATABRICKS_HOST: ${{ secrets.DATABRICKS_HOST }}
        run: databricks bundle validate

  deploy:
    needs: validate
    if: github.event_name == 'push' && github.ref == 'refs/heads/main' # Only deploy on push to main
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Databricks CLI Setup
        uses: databricks/setup-cli@v0.9.0

      - name: Deploy bundle
        env:
          DATABRICKS_TOKEN: ${{ secrets.DATABRICKS_TOKEN }}
          DATABRICKS_HOST: ${{ secrets.DATABRICKS_HOST }}
        run: databricks bundle deploy --target prod

Ressources supplémentaires

• Démarrage rapide pour GitHub Actions
• Comprendre les GitHub Actions
• Syntaxe de workflow pour les GitHub Actions