次の方法で共有


GitHub Actions

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 フェデレーション ポリシーを使用してアカウントに サービス プリンシパル を追加している必要があります。 GitHub Actions のワークロード ID フェデレーションを有効にするを参照してください。

重要

フェデレーション ポリシーのサブジェクト (フェデレーション トークンの ID) は、予想されるトークンのサブジェクトと正確に一致する必要があります。 この例では、エンティティの種類と名前は EnvironmentProd です。構築されたサブジェクトは、 repo:my-github-org-or-user/my-repo:environment:Prod形式である必要があります。

フェデレーション ポリシーを使用してサービス プリンシパルを作成したら、 DATABRICKS_HOST 環境変数を Azure Databricks ホスト ワークスペースに設定し、 DATABRICKS_CLIENT_ID 環境変数をサービス プリンシパル UUID に設定します。 DATABRICKS_AUTH_TYPE環境変数はアクションで設定されます。 Databricks 環境変数の詳細については、 統合認証の環境変数とフィールドを参照してください。

アクションを作成する

次に、次の 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:
  # These permissions are required for workload identity federation.
  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 }} # This is the service principal UUID.

    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

この例では、次のものが必要です。

  • ユーザー定義の環境変数 DATABRICKS_BUNDLE_ENV

  • リポジトリのルートにあるバンドル構成ファイル。このバンドル構成ファイルは、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 アクセス トークンを表します。 トークンを作成するには:

    1. Databricks サービス プリンシパルを作成します。 「アカウントにサービス プリンシパルを追加する」を参照してください
    2. サービス プリンシパルのシークレットを生成します。 「手順 1: OAuth シークレットを作成する」を参照してください。 シークレットとクライアント ID の値をコピーします。
    3. コピーしたシークレットとクライアント ID の値を使用して、Databricks アクセス トークン (アカウントまたはワークスペース) を手動で生成します。 アカウント レベルのアクセス トークンの生成を参照してください。
    4. JSON 応答から access_token 値をコピーします。 リポジトリの Actions に SP_TOKEN という名前の GitHub シークレットを追加し、シークレット値として Databricks アクセス トークンを使用します。 暗号化されたシークレットを参照してください。

    DATABRICKS_TOKEN 統合認証環境変数は、構成したSP_TOKENにアクション内で設定されます。

アクションを作成する

次に、次の 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

その他のリソース