GitHub Actions
Visualização
Esse recurso está em Public Preview.
O GitHub Actions aciona a execução de seus fluxos de CI/CD a partir de seus repositórios do GitHub e permite automatizar seu pipeline de CI/CD de compilação, teste e implantação.
Este artigo fornece informações sobre o site GitHub Actions desenvolvido pela Databricks e exemplos de casos de uso comuns. Para obter informações sobre outros CI/CD recursos e melhores práticas em Databricks, consulte CI/CD em Databricks e Melhores práticas e fluxos de trabalho recomendados CI/CD em Databricks.
Databricks GitHub Actions
Databricks desenvolveu o seguinte GitHub Actions para o senhor CI/CD fluxo de trabalho em GitHub. Adicione os arquivos YAML do GitHub Actions ao diretório .github/workflows do seu repositório.
Este artigo abrange o site GitHub Actions, que é desenvolvido por terceiros. Para entrar em contato com o provedor, consulte Suporte do GitHub Actions.
GitHub Actions | Descrição |
|---|---|
Uma ação composta que configura a CLI do Databricks em um fluxo de trabalho do GitHub Actions. |
execução de um fluxo de trabalho CI/CD que atualiza uma pasta Git
O seguinte exemplo de arquivo YAML GitHub Actions atualiza uma pasta Git workspace quando um branch remoto é atualizado. Para obter informações sobre a abordagem de pastas Git para CI/CD, consulte Outras ferramentas para controle de versão.
Requisitos
Este exemplo utiliza a federação de identidade de carga de trabalho para o GitHub Actions para maior segurança e requer que você tenha criado uma política de federação. Consulte Ativar a federação de identidade de carga de trabalho para o GitHub Actions.
Criar a ação
Agora adicione um arquivo .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
execução a CI/CD fluxo de trabalho com um pacote que execução a pipeline atualização
O seguinte exemplo de arquivo YAML GitHub Actions aciona uma implantação de teste que valida, implanta e executa o Job especificado no pacote dentro de um alvo de pré-produção chamado dev , conforme definido em um arquivo de configuração do pacote.
Requisitos
Este exemplo exige que haja:
-
Um arquivo de configuração de pacote na raiz do repositório, que é explicitamente declarado através da configuração do arquivo YAML do GitHub Actions
working-directory: .Este arquivo de configuração de pacote deve definir um fluxo de trabalho do Databricks chamadosample_jobe um alvo chamadodev. Por exemplo:YAML# 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_MANAGEPara obter mais informações sobre configuração de pacote configurável, consulte Configuração de pacote configurávelDatabricks ativo.
-
Um segredo GitHub chamado
SP_TOKEN, representando o access token Databricks para uma entidade de serviço Databricks que está associada ao workspace Databricks no qual este pacote está sendo implantado e executado. Para criar tokens:- Crie uma entidade de serviço do Databricks. Consulte Adicionar entidade de serviço à sua account.
- Gere um segredo para a entidade de serviço. Veja o passo 1: Criar um segredo OAuth. Copie os valores do segredo e do ID do cliente.
- Gere manualmente um access token Databricks (account ou workspace) usando os valores de segredo e ID do cliente copiados. Consulte Gerar um access tokenem nível account.
- Copie o valor
access_tokenda resposta JSON. Adicione um segredo GitHub chamadoSP_TOKENàs Ações em seu repositório e use o access token Databricks como o valor do segredo. Consulte Segredos criptografados.
Criar a ação
Agora adicione um arquivo .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
Talvez você também queira acionar implantações de produção. O seguinte arquivo YAML do GitHub Actions 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
execução a CI/CD fluxo de trabalho que constrói um JAR e implanta um bundle
Se você possui um ecossistema baseado em Java, o GitHub Actions precisa compilar e upload um JAR antes de implantar o pacote. O seguinte exemplo de arquivo YAML GitHub Actions aciona uma implantação que cria e carrega um JAR para 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 os passos de compilação para um projeto baseado em Scalasão semelhantes.
Requisitos
Este exemplo exige que haja:
- Um arquivo de configuração do pacote na raiz do repositório, que é declarado explicitamente por meio da configuração do arquivo YAML do GitHub Actions
working-directory: . - Um
DATABRICKS_TOKENvariável de ambiente que representa os tokens de acesso Databricks que estão associados ao Databricks workspace no qual este pacote está sendo implantado e executado. - Um
DATABRICKS_HOSTvariável de ambiente que representa o Databricks host workspace.
Criar a ação
Agora adicione um arquivo .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