重要
この機能は パブリック プレビュー段階です。
GitHub Actions は 、GitHub リポジトリから CI/CD フローの実行をトリガーし、ビルド、テスト、デプロイの CI/CD パイプラインを自動化できるようにします。
この記事では、Databricks によって開発された GitHub Actions と一般的なユース ケースの例について説明します。 Databricks のその他の CI/CD 機能とベスト プラクティスについては、 Azure Databricks の CI/CD と Databricks の ベスト プラクティスと推奨される CI/CD ワークフローを参照してください。
Databricks GitHub アクション
Databricks は、GitHub 上の CI/CD ワークフロー用に次の GitHub Actions を 開発しました。 GitHub Actions YAML ファイルをリポジトリの .github/workflows ディレクトリに追加します。
注
この記事では、サード パーティによって開発された GitHub Actions について説明します。 プロバイダーに問い合わせるには、 GitHub Actions のサポートを参照してください。
| GitHub アクション | 説明 |
|---|---|
| databricks/setup-cli | GitHub Actions ワークフローで Databricks CLI を設定する複合アクション。 |
Git フォルダーを更新する CI/CD ワークフローを実行する
次の GitHub Actions YAML ファイルの例では、リモート ブランチが更新されたときにワークスペースの Git フォルダーを更新します。 CI/CD の Git フォルダー アプローチの詳細については、「 ソース管理用のその他のツール」を参照してください。
Requirements
この例では、セキュリティ強化のために GitHub Actions のワークロード ID フェデレーションを使用し、フェデレーション ポリシーを作成する必要があります。 GitHub Actions のワークロード ID フェデレーションを有効にするを参照してください。
アクションを作成する
次に、次の YAML を使用してリポジトリにファイル .github/workflows/sync_git_folder.yml を追加します。
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
パイプライン更新を実行するバンドルを使用して CI/CD ワークフローを実行する
次の GitHub Actions YAML ファイルの例では、バンドル構成ファイル内で定義されている dev という名前の実稼働前ターゲット内で、バンドル内の指定されたジョブを検証、デプロイ、および実行するテスト デプロイをトリガーします。
Requirements
この例では、次のものが必要です。
リポジトリのルートにあるバンドル構成ファイル。このバンドル構成ファイルは、GitHub Actions YAML ファイルの設定を通じて明示的に宣言されます
working-directory: .このバンドル構成ファイルでは、sample_jobという名前の Azure Databricks ワークフローとdevという名前のターゲットを定義する必要があります。 例えば次が挙げられます。# 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_MANAGEバンドル構成の詳細については、「 Databricks Asset Bundle の構成」を参照してください。
SP_TOKENという名前の GitHub シークレット。このバンドルがデプロイおよび実行されている Azure Databricks ワークスペースに関連付けられている Azure Databricks サービス プリンシパルの Azure Databricks アクセス トークンを表します。 トークンを作成するには:- Databricks サービス プリンシパルを作成します。 「アカウントにサービス プリンシパルを追加する」を参照してください。
- サービス プリンシパルのシークレットを生成します。 「手順 1: OAuth シークレットを作成する」を参照してください。 シークレットとクライアント ID の値をコピーします。
- コピーしたシークレットとクライアント ID の値を使用して、Databricks アクセス トークン (アカウントまたはワークスペース) を手動で生成します。 アカウント レベルのアクセス トークンの生成を参照してください。
- JSON 応答から
access_token値をコピーします。 リポジトリの Actions にSP_TOKENという名前の GitHub シークレットを追加し、シークレット値として Databricks アクセス トークンを使用します。 暗号化されたシークレットを参照してください。
アクションを作成する
次に、次の YAML を使用してリポジトリにファイル .github/workflows/pipeline_update.yml を追加します。
# 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
運用環境のデプロイをトリガーすることもできます。 次の GitHub Actions YAML ファイルは、上記のファイルと同じリポジトリに存在できます。 このファイルは、バンドル構成ファイル内で定義されている "prod" という名前の運用ターゲット内で、指定されたバンドルを検証、デプロイ、および実行します。
# 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
JAR をビルドしてバンドルをデプロイする CI/CD ワークフローを実行する
Java ベースのエコシステムがある場合、GitHub アクションでは、バンドルをデプロイする前に JAR をビルドしてアップロードする必要があります。 次の例の GitHub Actions YAML ファイルは、JAR をビルドしてボリュームにアップロードするデプロイをトリガーし、バンドル構成ファイル内で定義されている "prod" という名前の運用ターゲットにバンドルを検証してデプロイします。 Java ベースの JAR をコンパイルしますが、Scala ベースのプロジェクトのコンパイル手順は似ています。
Requirements
この例では、次のものが必要です。
- リポジトリのルートにあるバンドル構成ファイル。GitHub Actions YAML ファイルの設定を使用して明示的に宣言されます。
working-directory: . - このバンドルをデプロイして実行する Azure Databricks ワークスペースに関連付けられている Azure Databricks アクセス トークンを表す
DATABRICKS_TOKEN環境変数。 - Azure Databricks ホスト ワークスペースを表す
DATABRICKS_HOST環境変数。
アクションを作成する
次に、次の YAML を使用してリポジトリにファイル .github/workflows/build_jar.yml を追加します。
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