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