Skip to main content

Actions での Dependabot のトラブルシューティング

Dependabot は、pull request とコメントで Actions ワークフローをトリガーできます。ただし、特定のイベントは異なる方法で処理されます。

pull_requestpull_request_reviewpull_request_review_commentpushcreatedeploymentdeployment_status イベントを使って Dependabot (.actor == 'dependabot[bot]') によって開始されたワークフローの場合、次の制限が適用されます。

  • _TOKEN は、既定で読み取り専用のアクセス許可を持ちます。
  • シークレットは、Dependabot シークレットから設定されます。 Actions シークレットは使用できません。

pull_request_target イベントを使い Dependabot によって開始されたワークフロー (.actor == 'dependabot[bot]') については、pull request のベース参照が Dependabot によって作成された場合 (.event.pull_request.user.login == 'dependabot[bot]')、_TOKEN は読み取り専用であり、シークレットは使用できません。

これらの制限は、ワークフローが別のアクターによって再実行された場合でも適用されます。

詳しくは、「 Actions およびワークフローのセキュリティ保護の維持: pwn 要求の阻止」を参照してください。

.comに対して Dependabot の更新プログラムを設定した後、Dependabot イベントによって既存のワークフローがトリガーされるとエラーが発生することがあります。

既定では、pushpull_requestpull_request_review、または pull_request_review_comment のイベントから Dependabot によってトリガーされる Actions ワークフローの実行は、リポジトリ フォークから開かれたかのように扱われます。 他のアクターによってトリガーされるワークフローとは異なり、これは読み取り専用の _TOKEN を受け取り、通常使用できるシークレットにはアクセスできないことを意味します。 これにより、Dependabot によってトリガーされたときに、リポジトリへの書き込みを試みるワークフローが失敗します。

この問題を解決するには、次の 3 つの方法があります。

  1. if: .actor != 'dependabot[bot]' のような式を使用して、Dependabot によってトリガーされないようにワークフローを更新できます。 詳しくは、「ワークフローとアクションで式を評価する」をご覧ください。
  2. ワークフローを変更して、このような制限がない pull_request_target を含む 2 段階のプロセスを使用できます。 詳しくは、「 Actions での Dependabot のトラブルシューティング」をご覧ください。
  3. Dependabot のアクセスによってトリガーされるワークフローをシークレットに提供し、permissions という用語で _TOKEN の既定のスコープを広げることができます。

この記事では、いくつかのトラブルシューティングに関するアドバイスを提供します。 「 Actions のワークフロー構文」も参照してください。

Dependabot イベントでワークフローがトリガーされる場合、ワークフローで使用できるシークレットは Dependabot シークレットのみです。 Actions シークレットは使用できません。 そのため、Dependabot イベントによってトリガーされるワークフローで使われるシークレットはすべて、Dependabot シークレットとして格納する必要があります。 詳しくは、「Dependabot のプライベート レジストリへのアクセスの構成」をご覧ください。

Dependabot シークレットは secrets コンテキストに追加され、 Actions のシークレットとまったく同じ構文を使用して参照されます。 詳しくは、「 Actions でのシークレットの使用」をご覧ください。

Dependabot や他のアクターによってトリガーされるワークフローがある場合、最もシンプルな解決策は、アクションで、および同じ名前を持つ Dependabot シークレットで必要なアクセス許可を持つトークンを格納することです。 その後、ワークフローには、これらのシークレットへの 1 回の呼び出しを含めることができます。 Dependabot のシークレットの名前が異なる場合は、条件を使用して、使用するアクターごとに適切なシークレットを指定します。

条件を使う例については、「 ActionsでのDependabotの自動化」を参照してください。

ユーザー名とパスワードを使用して AWS 上のプライベート コンテナー レジストリにアクセスするには、ワークフローに usernamepassword のシークレットを含める必要があります。

この例では、Dependabot によってワークフローをトリガーされると、READONLY_AWS_ACCESS_KEY_IDREADONLY_AWS_ACCESS_KEY という Dependabot シークレットが使われます。 別のアクターでワークフローがトリガーされる場合は、それらの名前を持つアクション シークレットが使用されます。

YAML
name: CI
on:
  pull_request:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Login to private container registry for dependencies
        uses: docker/login-action@3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c
        with:
          registry: https://1234567890.dkr.ecr.us-east-1.amazonaws.com
          username: ${{ secrets.READONLY_AWS_ACCESS_KEY_ID }}
          password: ${{ secrets.READONLY_AWS_ACCESS_KEY }}

      - name: Build the Docker image
        run: docker build . --file Dockerfile --tag my-image-name:$(date +%s)

既定では、Dependabot によってトリガーされる Actions ワークフローでは、読み取り専用のアクセス許可を持つ _TOKEN を取得します。 ワークフローで permissions キーを使用すると、トークンのアクセスを増やすことができます。

YAML
name: CI
on: pull_request

# Set the access for individual scopes, or use permissions: write-all
permissions:
  pull-requests: write
  issues: write
  ...

jobs:
  ...

詳しくは、「自動トークン認証」をご覧ください。

Dependabot ワークフローを手動で再実行すると、再実行を開始したユーザーが異なる特権を持っていたとしても、以前と同じ特権で実行されます。 詳しくは、「ワークフローとジョブの再実行」をご覧ください。