Freigeben über

GitHub-Aktionen

Von Bedeutung

Dieses Feature befindet sich in der Public Preview.

GitHub Actions lösen Ausführungen Ihrer CI/CD-Abläufe aus Ihren GitHub-Repositories aus und ermöglichen es Ihnen, Ihre Erstellungs-, Test- und Bereitstellungs-CI/CD-Pipeline zu automatisieren.

Dieser Artikel enthält Informationen zu den GitHub-Aktionen, die von Databricks entwickelt wurden, und Beispiele für häufige Anwendungsfälle. Informationen zu anderen CI/CD-Features und bewährten Methoden für Databricks finden Sie unter CI/CD unter Azure Databricks und bewährte Methoden und empfohlene CI/CD-Workflows auf Databricks.

Databricks GitHub-Aktionen

Databricks hat die folgenden GitHub-Aktionen für Ihre CI/CD-Workflows auf GitHub entwickelt. Fügen Sie GitHub Actions YAML-Dateien zum Verzeichnis Ihres Repositorys .github/workflows hinzu.

Hinweis

Dieser Artikel behandelt GitHub-Aktionen, die von einem Drittanbieter entwickelt werden. Informationen zum Kontaktieren des Anbieters finden Sie unter GitHub Actions Support.

GitHub-Aktion BESCHREIBUNG
databricks/setup-cli Eine zusammengesetzte Aktion, die die Databricks CLI in einem GitHub Actions-Workflow einrichtet.

Ausführen eines CI/CD-Workflows, der einen Git-Ordner aktualisiert

In der folgenden YAML-Datei eines GitHub Actions-Beispiels wird ein Git-Ordner im Arbeitsbereich aktualisiert, wenn ein Remote-Branch aktualisiert wird. Informationen zum Git-Ordneransatz für CI/CD finden Sie unter "Weitere Tools für die Quellcodeverwaltung".

Anforderungen

In diesem Beispiel wird der Workload-Identitätsverbund für GitHub-Aktionen für erhöhte Sicherheit verwendet und erfordert, dass Sie eine Verbundrichtlinie erstellt haben. Siehe Workload-Identitätsverbund für GitHub-Actions aktivieren.

Erstellen der Aktion

Fügen Sie ihrem Repository nun eine Datei .github/workflows/sync_git_folder.yml mit dem folgenden YAML hinzu:

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

Ausführen eines CI/CD-Workflows mit einem Bundle, das ein Pipelineupdate ausführt

Im folgenden Beispiel löst die GitHub Actions YAML-Datei eine Testbereitstellung aus, die den angegebenen Job im Bundle innerhalb eines Vorproduktionsziels dev validiert, bereitstellt und ausführt, wie in der Bundlekonfigurationsdatei definiert.

Anforderungen

In diesem Beispiel ist Folgendes erforderlich:

  • Eine Bündelkonfigurationsdatei im Stammverzeichnis des Repositorys, die explizit über die Einstellung working-directory: . der YAML-Datei für GitHub-Aktionen deklariert wird. Diese Bündelkonfigurationsdatei sollte einen Azure Databricks-Workflow namens sample_job und ein Ziel namens dev definieren. Beispiel:

    # 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

    Weitere Informationen zur Konfiguration des Bundles finden Sie unter Databricks Asset Bundle-Konfiguration.

  • Ein GitHub-Geheimschlüssel SP_TOKEN, der das Azure Databricks-Zugriffstoken für einen Azure Databricks-Dienstprinzipal darstellt, der dem Azure Databricks-Arbeitsbereich zugeordnet ist, für den dieses Bundle bereitgestellt und ausgeführt wird. So erstellen Sie ein Token:

    1. Erstellen Sie einen Databricks-Dienstprinzipal. Siehe "Dienstprinzipale hinzufügen" zu Ihrem Konto.
    2. Generieren Sie einen geheimen Schlüssel für den Dienstprinzipal. Siehe Schritt 1: Erstellen eines OAuth-Schlüssels. Kopieren Sie die Werte des geheimen Schlüssels und der Client-ID.
    3. Generieren Sie manuell ein Databricks-Zugriffstoken (Konto oder Arbeitsbereich) mithilfe der kopierten Geheim- und Client-ID-Werte. Siehe Generieren eines Zugriffstokens auf Kontoebene.
    4. Kopieren Sie den access_token Wert aus der JSON-Antwort. Fügen Sie einen GitHub-Geheimschlüssel namens SP_TOKEN zu Actions in Ihrem Repository hinzu und verwenden Sie das Databricks-Zugriffstoken als geheimen Wert. Weitere Informationen finden Sie unter "Verschlüsselte Geheime Schlüssel".

Erstellen der Aktion

Fügen Sie ihrem Repository nun eine Datei .github/workflows/pipeline_update.yml mit dem folgenden YAML hinzu:

# 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

Sie können auch Produktionsbereitstellungen auslösen. Die folgende GitHub Actions YAML-Datei kann in demselben Repository wie die vorherige Datei vorhanden sein. Diese Datei überprüft, stellt das angegebene Bundle innerhalb eines Produktionsziels namens "prod" gemäß Definition in einer Bündelkonfigurationsdatei bereit und führt es aus.

# 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

Ausführen eines CI/CD-Workflows, der ein JAR erstellt und ein Bundle bereitstellt

Wenn Sie über ein Java-basiertes Ökosystem verfügen, muss Ihre GitHub-Aktion einen JAR erstellen und hochladen, bevor Sie das Bundle bereitstellen. Im folgenden Beispiel löst die YAML-Datei von GitHub Actions eine Bereitstellung aus, die eine JAR-Datei erstellt und auf ein Volume hochlädt. Anschließend wird das Bundle, wie in der Bundlekonfigurationsdatei definiert, überprüft und im Produktionsziel „prod“ bereitgestellt. Es kompiliert einen javabasierten JAR, aber die Kompilierungsschritte für ein Skala-basiertes Projekt sind ähnlich.

Anforderungen

In diesem Beispiel ist Folgendes erforderlich:

  • Eine Bündelkonfigurationsdatei im Root-Verzeichnis des Repositorys, die explizit über die Einstellungen der YAML-Datei für GitHub Actions deklariert wird working-directory: .
  • Eine DATABRICKS_TOKEN Umgebungsvariable, die das Azure Databricks-Zugriffstoken darstellt, das dem Azure Databricks-Arbeitsbereich zugeordnet ist, für den dieses Bundle bereitgestellt und ausgeführt wird.
  • Eine DATABRICKS_HOST Umgebungsvariable, die den Azure Databricks-Hostarbeitsbereich darstellt.

Erstellen der Aktion

Fügen Sie ihrem Repository nun eine Datei .github/workflows/build_jar.yml mit dem folgenden YAML hinzu:

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

Weitere Ressourcen

  • Last updated on