Partilhar via


GitHub Actions

Importante

Este recurso está no Public Preview.

As Ações do GitHub desencadeiam as execuções dos teus fluxos de CI/CD a partir dos teus repositórios do GitHub e permitem-te automatizar o teu pipeline de compilação, teste e implementação de CI/CD.

Este artigo fornece informações sobre as Ações do GitHub desenvolvidas pela Databricks e exemplos de casos de uso comuns. Para obter informações sobre outros recursos de CI/CD e práticas recomendadas no Databricks, consulte CI/CD no Azure Databricks e Práticas recomendadas e fluxos de trabalho de CI/CD recomendados no Databricks.

Ações do Databricks no GitHub

A Databricks desenvolveu as seguintes Ações do GitHub para seus fluxos de trabalho de CI/CD no GitHub. Adicione arquivos YAML do GitHub Actions ao diretório do .github/workflows seu repo.

Observação

Este artigo abrange as Ações do GitHub, que são desenvolvidas por terceiros. Para entrar em contacto com o provedor, consulte Suporte do GitHub Actions.

Ação GitHub Descrição
databricks/setup-cli Uma ação composta que configura a CLI do Databricks em um fluxo de trabalho de Ações do GitHub.

Executa um fluxo de trabalho CI/CD que atualiza uma pasta Git

O exemplo a seguir: o arquivo YAML de ações do GitHub atualiza uma pasta Git do espaço de trabalho quando uma ramificação remota é atualizada. Para informações sobre a abordagem de pasta Git para CI/CD, veja Outras ferramentas para controlo de versão.

Requerimentos

Este exemplo utiliza a federação de identidade de carga de trabalho para GitHub Actions para maior segurança e exige que tenha criado uma política de federação. Consulte Habilitar federação de identidade de carga de trabalho para ações do GitHub.

Criar a Ação

Agora adicione um ficheiro .github/workflows/sync_git_folder.yml ao seu repositório com o seguinte YAML:

name: Sync Git Folder

concurrency: prod_environment

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

permissions:
  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 }}

    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

Execute um fluxo de trabalho de CI/CD com um pacote que realiza uma atualização da pipeline

O seguinte exemplo do ficheiro YAML GitHub Actions desencadeia uma implementação de teste que valida, implementa e executa o trabalho especificado no bundle dentro de um destino de pré-produção nomeado dev conforme definido num ficheiro de configuração bundle.

Requerimentos

Este exemplo requer que haja:

  • Um arquivo de configuração de pacote na raiz do repositório, que é explicitamente declarado por meio da configuração working-directory: . do arquivo YAML de Ações do GitHub Esse arquivo de configuração de pacote deve definir um fluxo de trabalho do Azure Databricks nomeado sample_job e um destino chamado dev. Por exemplo:

    # This is a Databricks asset 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
    

    Para mais informações sobre a configuração do bundle, consulte a configuração do Databricks Asset Bundle.

  • Um segredo do GitHub chamado SP_TOKEN, que representa o token de acesso do Azure Databricks para uma entidade de serviço do Azure Databricks associada ao espaço de trabalho do Azure Databricks onde este pacote está a ser implementado e executado. Para criar um token:

    1. Crie um principal de serviço do Databricks. Consulte Adicionar entidades de serviço à sua conta.
    2. Cria um segredo para o diretor do serviço. Consulte Etapa 1: Criar um segredo OAuth. Copie os valores do segredo e do ID do cliente.
    3. Gerar manualmente um token de acesso Databricks (conta ou espaço de trabalho) usando os valores de segredo e ID de cliente copiados. Consulte Gerar um token de acesso no nível da conta.
    4. Copie o access_token valor da resposta JSON. Adicione um segredo do GitHub chamado SP_TOKEN às Ações no seu repositório e use o token de acesso Databricks como valor do segredo. Consulte Segredos criptografados.

Criar a Ação

Agora adicione um ficheiro .github/workflows/pipeline_update.yml ao seu repositório com o seguinte 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

Pode também querer iniciar implementações de produção. O seguinte arquivo YAML de ações do GitHub pode existir no mesmo repositório que o arquivo anterior. Esse arquivo valida, implanta e executa o pacote especificado em um destino de produção chamado "prod", conforme definido em um arquivo de configuração de pacote.

# 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

Executar um fluxo de trabalho de CI/CD que cria um JAR e implanta um pacote

Se tiver um ecossistema baseado em Java, a sua GitHub Action precisa de construir e carregar um JAR antes de implementar o bundle. O exemplo a seguir do arquivo YAML do GitHub Actions aciona uma implantação que cria e carrega um JAR em um volume e, em seguida, valida e implanta o pacote em um destino de produção chamado "prod", conforme definido no arquivo de configuração do pacote. Ele compila um JAR baseado em Java, mas as etapas de compilação para um projeto baseado em Scala são semelhantes.

Requerimentos

Este exemplo requer que haja:

  • Um arquivo de configuração de pacote na raiz do repositório, que é explicitamente declarado por meio da configuração do arquivo YAML de Ações do GitHub working-directory: .
  • Uma DATABRICKS_TOKEN variável de ambiente que representa o token de acesso do Azure Databricks associado ao espaço de trabalho do Azure Databricks no qual esse pacote está sendo implantado e executado.
  • Uma DATABRICKS_HOST variável de ambiente que representa o espaço de trabalho de host do Azure Databricks.

Criar a Ação

Agora adicione um ficheiro .github/workflows/build_jar.yml ao seu repositório com o seguinte 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

Recursos adicionais