Uruchamianie przepływu pracy ciągłej integracji/ciągłego wdrażania za pomocą pakietu zasobów usługi Databricks i funkcji GitHub Actions
W tym artykule opisano sposób uruchamiania przepływu pracy ciągłej integracji/ciągłego wdrażania w usłudze GitHub przy użyciu funkcji GitHub Actions i pakietu zasobów usługi Databricks. Zobacz Co to są pakiety zasobów usługi Databricks?
Możesz użyć funkcji GitHub Actions wraz z poleceniami interfejsu wiersza polecenia bundle
usługi Databricks, aby zautomatyzować, dostosować i uruchomić przepływy pracy ciągłej integracji/ciągłego wdrażania z poziomu repozytoriów Usługi GitHub.
Do katalogu repozytorium .github/workflows
można dodać pliki YAML funkcji GitHub Actions, takie jak następujące. Poniższy przykładowy plik YAML funkcji GitHub Actions weryfikuje, wdraża i uruchamia określone zadanie w pakiecie w przedprodukcyjnym obiekcie docelowym o nazwie "qa" zgodnie z definicją w pliku konfiguracji pakietu. Ten przykładowy plik YAML funkcji GitHub Actions opiera się na następujących kwestiach:
- Plik konfiguracji pakietu w katalogu głównym repozytorium, który jest jawnie zadeklarowany za pomocą ustawienia
working-directory: .
pliku YAML funkcji GitHub Actions (to ustawienie można pominąć, jeśli plik konfiguracji pakietu znajduje się już w katalogu głównym repozytorium). Ten plik konfiguracji pakietu definiuje przepływ pracy usługi Azure Databricks o nazwie i element docelowy o nazwiemy-job
qa
. Zobacz Konfiguracja pakietu zasobów usługi Databricks. - Wpis tajny usługi GitHub o nazwie
SP_TOKEN
, reprezentujący token dostępu usługi Azure Databricks dla jednostki usługi Azure Databricks skojarzonej z obszarem roboczym usługi Azure Databricks, do którego jest wdrażany i uruchamiany ten pakiet. Zobacz Zaszyfrowane wpisy tajne.
# This workflow validates, deploys, and runs the specified bundle
# within a pre-production target named "qa".
name: "QA 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 "qa" target as defined
# in the bundle's settings file.
- run: databricks bundle deploy
working-directory: .
env:
DATABRICKS_TOKEN: ${{ secrets.SP_TOKEN }}
DATABRICKS_BUNDLE_ENV: qa
# 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: qa
Poniższy plik YAML funkcji GitHub Actions może istnieć w tym samym repozytorium co poprzedni plik. Ten plik weryfikuje, wdraża i uruchamia określony pakiet w środowisku docelowym produkcyjnym o nazwie "prod" zgodnie z definicją w pliku konfiguracji pakietu. Ten przykładowy plik YAML funkcji GitHub Actions opiera się na następujących kwestiach:
- Plik konfiguracji pakietu w katalogu głównym repozytorium, który jest jawnie zadeklarowany za pośrednictwem ustawienia
working-directory: .
pliku YAML funkcji GitHub Actions (to ustawienie można pominąć, jeśli plik konfiguracji pakietu znajduje się już w katalogu głównym repozytorium). Ten plik konfiguracji pakietu definiuje przepływ pracy usługi Azure Databricks o nazwie i element docelowy o nazwiemy-job
prod
. Zobacz Konfiguracja pakietu zasobów usługi Databricks. - Wpis tajny usługi GitHub o nazwie
SP_TOKEN
, reprezentujący token dostępu usługi Azure Databricks dla jednostki usługi Azure Databricks skojarzonej z obszarem roboczym usługi Azure Databricks, do którego jest wdrażany i uruchamiany ten pakiet. Zobacz Zaszyfrowane wpisy tajne.
# 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