Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Importante
Esse recurso está em Visualização Pública.
O GitHub Actions dispara execuções dos fluxos de CI/CD de seus repositórios do GitHub e permite automatizar o pipeline de CI/CD de build, teste e implantação.
Este artigo fornece informações sobre as Ações do GitHub desenvolvidas pelo Databricks e exemplos para 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 no GitHub do Databricks
O 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 repositório.
Observação
Este artigo aborda o GitHub Actions, que é desenvolvido por terceiros. Para entrar em contato com o provedor, consulte o Suporte do GitHub Actions.
| Ação do GitHub | Descrição |
|---|---|
| databricks/setup-cli | Uma ação composta que configura a CLI do Databricks em um fluxo de trabalho do GitHub Actions. |
Executar um fluxo de trabalho de CI/CD que atualiza uma pasta git de produção
O exemplo a seguir de arquivo YAML do GitHub Actions atualiza uma pasta Git do espaço de trabalho quando um branch remoto é atualizado. Para obter informações sobre a abordagem de pasta de produção do Git para CI/CD, consulte Outras ferramentas para controle de código-fonte.
Este exemplo usa a federação de identidade de carga de trabalho para o GitHub Actions para segurança aprimorada e exige que você siga primeiro as etapas em Habilitar federação de identidade de carga de trabalho para o GitHub Actions para criar uma política de federação.
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
Executar um fluxo de trabalho de CI/CD com um pacote que executa uma atualização de pipeline
O arquivo YAML do GitHub Actions mostrado a seguir aciona uma implantação de teste que valida, implanta e executa o trabalho especificado no pacote dentro de um alvo de pré-produção chamado "dev", conforme definido em um arquivo de configuração do pacote.
Este exemplo requer que haja:
- Um arquivo de configuração de pacote na raiz do repositório, que é declarado explicitamente por meio da configuração
working-directory: .do arquivo YAML do GitHub Actions Este arquivo de configuração de pacote deve definir um fluxo de trabalho do Azure Databricks nomeadomy-jobe um destino nomeadodev. Confira Configuração do Pacote de Ativos do Databricks. - Um segredo do GitHub chamado
SP_TOKEN, representando o token de acesso do Azure Databricks para uma entidade de serviço do Azure Databricks associada ao workspace do Azure Databricks no qual esse pacote está sendo implantado e executado. Consulte segredos criptografados.
# 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 "my-job" as defined in the
# bundle that was just deployed.
- run: databricks bundle run my-job --refresh-all
working-directory: .
env:
DATABRICKS_TOKEN: ${{ secrets.SP_TOKEN }}
DATABRICKS_BUNDLE_ENV: dev
Talvez você também queira disparar implantações de produção. O arquivo YAML do GitHub Actions a seguir 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 "my-job" as defined in the
# bundle that was just deployed.
- run: databricks bundle run my-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 você tiver um ecossistema baseado em Java, o GitHub Action precisará criar e carregar um JAR antes de implantar o pacote. O exemplo a seguir, o arquivo YAML do GitHub Actions dispara uma implantação que compila 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.
Este exemplo requer que haja:
- Um arquivo de configuração de pacote na raiz do repositório, que é declarado explicitamente por meio da configuração do arquivo YAML do GitHub Actions
working-directory: . - Uma
DATABRICKS_TOKENvariável de ambiente que representa o token de acesso do Azure Databricks associado ao workspace do Azure Databricks ao qual esse pacote está sendo implantado e executado. - Uma
DATABRICKS_HOSTvariável de ambiente que representa o workspace de host do Azure Databricks.
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