Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Ważne
Ta funkcja jest dostępna w publicznej wersji testowej.
GitHub Actions uruchamia przepływy CI/CD z twoich repozytoriów GitHub i pozwala na automatyzację potoku budowania, testowania i wdrażania CI/CD.
Ten artykuł zawiera informacje o funkcji GitHub Actions opracowanej przez usługę Databricks i przykłady typowych przypadków użycia. Aby uzyskać informacje o innych funkcjach ciągłej integracji/ciągłego wdrażania i najlepszych rozwiązaniach dotyczących usługi Databricks, zobacz Ciągła integracja/ciągłe wdrażanie w usłudze Azure Databricks i najlepsze rozwiązania oraz zalecane przepływy pracy ciągłej integracji/ciągłego wdrażania w usłudze Databricks.
Databricks GitHub Actions
Databricks opracowało następujące funkcje GitHub Actions dla przepływów pracy ciągłej integracji/ciągłego wdrażania na GitHub. Dodaj pliki YAML GitHub Actions do katalogu repozytorium .github/workflows.
Uwaga / Notatka
W tym artykule opisano funkcję GitHub Actions, która jest opracowywana przez inną firmę. Aby skontaktować się z dostawcą, zobacz Wsparcie GitHub Actions.
| Akcja usługi GitHub | Opis |
|---|---|
| Databricks/setup-cli | Złożona akcja, która ustawia interfejs wiersza polecenia usługi Databricks w przepływie pracy GitHub Actions. |
Uruchom przepływ pracy CI/CD, który aktualizuje folder Git w produkcji
Poniższy przykładowy plik YAML GitHub Actions aktualizuje folder Git w obszarze roboczym, gdy zdalna gałąź zostanie zaktualizowana. Aby uzyskać informacje o podejściu do repozytorium Production Git dla ciągłej integracji/ciągłego wdrażania, zobacz Inne narzędzia do kontroli wersji.
W tym przykładzie użyto federacji tożsamości obciążenia dla funkcji GitHub Actions w celu zwiększenia bezpieczeństwa i należy najpierw wykonać kroki opisane w temacie Włączanie federacji tożsamości obciążenia dla funkcji GitHub Actions w celu utworzenia zasad federacyjnych.
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
Uruchomić workflow CI/CD z pakietem, który uruchamia aktualizację potoku
Poniższy przykładowy plik YAML funkcji GitHub Actions wyzwala wdrożenie testowe, które weryfikuje, wdraża i uruchamia określone zadanie w pakiecie w przedprodukcyjnym obiekcie docelowym o nazwie "dev" zgodnie z definicją w pliku konfiguracji pakietu.
Ten przykład wymaga, aby istniało:
- Plik konfiguracji pakietu w katalogu głównym repozytorium, który jest jawnie zadeklarowany za pomocą ustawienia
working-directory: .pliku YAML dla GitHub Actions. Ten plik konfiguracji pakietu powinien zdefiniować przepływ pracy nazwanymy-joboraz cel nazwanydevdla Azure Databricks. 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 "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
Może być również konieczne wyzwolenie wdrożeń produkcyjnych. 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.
# 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
Uruchom przepływ pracy CI/CD, który buduje JAR i wdraża pakiet
Jeśli masz ekosystem oparty na języku Java, akcja usługi GitHub musi skompilować i przekazać plik JAR przed wdrożeniem pakietu. Poniższy przykładowy plik YAML dla funkcji GitHub Actions inicjuje wdrożenie, które kompiluje plik JAR i przesyła go do woluminu. Następnie weryfikuje i wdraża pakiet na docelowe środowisko produkcyjne o nazwie "prod", zgodnie z definicją zawartą w pliku konfiguracji bundla. Kompiluje on plik JAR oparty na języku Java, ale kroki kompilacji projektu opartego na języku Scala są podobne.
Ten przykład wymaga, aby istniało:
- Plik konfiguracyjny pakietu w katalogu głównym repozytorium, jawnie zadeklarowany w ustawieniach pliku YAML dla GitHub Actions
working-directory: . - Zmienna
DATABRICKS_TOKENśrodowiskowa reprezentująca token dostępu usługi Azure Databricks skojarzony z obszarem roboczym usługi Azure Databricks, do którego jest wdrażany i uruchamiany pakiet. - Zmienna
DATABRICKS_HOSTśrodowiskowa reprezentująca obszar roboczy hosta usługi 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