Pular para o conteúdo principal

GitHub Actions

info

Visualização

Esse recurso está em Public Preview.

GitHub Actions pode ser usado para acionar a execução de seu CI/CD fluxo de trabalho a partir de seus repositórios GitHub e permite que o senhor automatize a criação, o teste e a implantação CI/CD pipeline.

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.

nota

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

databricks/setup-CLI

Uma ação composta que configura a CLI do Databricks em um fluxo de trabalho do GitHub Actions.

execução a CI/CD fluxo de trabalho que atualiza a pasta Production Git

O seguinte exemplo de arquivo YAML GitHub Actions atualiza uma pasta workspace Git quando uma ramificação remota é atualizada. Para obter informações sobre a abordagem da pasta Production Git para CI/CD, consulte a pasta Production Git.

Este exemplo usa a federação de identidade de carga de trabalho para GitHub Actions para aumentar a segurança e exige que o senhor siga primeiro as etapas em Habilitar federação de identidade de carga de trabalho para GitHub Actions para criar uma política de federação.

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 GitHub Actions YAML aciona uma implementação de teste que valida, implanta e executa o trabalho especificado no pacote em um destino de pré-produção chamado "dev", conforme definido em um arquivo de configuração do pacote.

Este exemplo exige 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: . Esse arquivo de configuração de pacote deve definir um fluxo de trabalho do Databricks chamado my-job e um destino chamado dev. Consulte Databricks ativo Bundle configuration.
  • Um segredo GitHub denominado SP_TOKEN, representando os tokens de acesso Databricks para uma Databricks entidade de serviço que está associada à Databricks workspace na qual este pacote está sendo implantado e executado. Consulte Segredos criptografados.
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 "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 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.

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 "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

execução a CI/CD fluxo de trabalho que constrói um JAR e implanta um bundle

Se o senhor tiver um ecossistema baseado em Java, seu GitHub Actions precisará criar e upload um JAR antes de implantar o pacote. O seguinte exemplo de arquivo GitHub Actions YAML aciona uma implementaçã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 "e", conforme definido no arquivo de configuração do pacote. Ele compila um JAR baseado em Java, mas as etapas de compilação de um projeto baseado em Scala são semelhantes.

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_TOKEN variá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_HOST variável de ambiente que representa o Databricks host workspace.
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

Recurso adicional