ci(website): preview skips Dependabot PRs and fires on ready_for_review#5454
Conversation
Dependabot PRs run without repository secrets by GitHub policy, so the preview deploy can never succeed there — skip instead of failing red. Also run when a draft flips to ready, which previously produced no run. Claude-Session: https://claude.ai/code/session_013Qe1Vf2yvj33BVd5W1q7HB
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Website previewPreview URL: https://pr-5454-agenta-website-preview.mahmoud-637.workers.dev Built from |
📝 WalkthroughSummary by CodeRabbit
WalkthroughThe website preview workflow now triggers on ChangesWebsite preview workflow
Estimated code review effort: 1 (Trivial) | ~5 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 Checkov (3.3.8).github/workflows/15-website-preview.ymlTraceback (most recent call last): Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: fe46cc66-2f1c-4502-aaf9-999807b4b0ca
📒 Files selected for processing (1)
.github/workflows/15-website-preview.yml
| # Dependabot PRs run without repository secrets (GitHub policy), so the | ||
| # deploy could never succeed there; skip them cleanly instead of failing. | ||
| if: >- | ||
| github.event_name == 'workflow_dispatch' || | ||
| (github.event.pull_request.head.repo.full_name == github.repository && | ||
| !github.event.pull_request.draft) | ||
| !github.event.pull_request.draft && | ||
| github.actor != 'dependabot[bot]') |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Workflow file:"
cat -n .github/workflows/15-website-preview.yml | sed -n '1,80p'
echo
echo "Pull request event context docs/usages in workflows (if any):"
rg -n "github\.event\.pull_request|github\.actor|pull_request\.user|workflow_dispatch" .github/workflows || trueRepository: Agenta-AI/agenta
Length of output: 20161
🌐 Web query:
GitHub Actions github.actor pull_request user login context dependabot workflow_dispatch
💡 Result:
In GitHub Actions, the context variables github.actor and github.triggering_actor serve different purposes, and their behavior with Dependabot and manual triggers has critical security and workflow implications [1][2]. github.actor This represents the user or app that triggered the workflow run [1][2]. For Dependabot, this value is 'dependabot[bot]' when the workflow is initially triggered by a Dependabot-opened PR or event [3]. It is important to note that github.actor is not always the author of the pull request; it is the entity that caused the most recent event to trigger the workflow [4][3]. If a human pushes a commit to a Dependabot-authored PR, github.actor will reflect that human user instead of 'dependabot[bot]' [3]. github.triggering_actor This represents the user who initiated the workflow run [1][2]. This is particularly relevant for re-runs: if a user manually re-runs a workflow, github.triggering_actor will be that user, while github.actor remains the entity that triggered the initial run [1][5]. Workflow privileges (such as secrets and permissions) are consistently determined by the original github.actor to maintain security stability during re-runs [1][5]. Dependabot and Security Context Workflows triggered by Dependabot are often treated as if they originate from a repository fork [6][7]. This imposes security restrictions by default: - Read-only GITHUB_TOKEN permissions [6][7]. - Absence of standard GitHub Actions secrets (only Dependabot secrets are available) [6][7]. - Bypassing some repository-level policy checks [8]. Using if: github.actor == 'dependabot[bot]' as a sole trust boundary is considered unsafe because it does not verify the actual author of the pull request [4]. To securely gate workflows or differentiate behavior, it is recommended to verify the PR author using github.event.pull_request.user.login == 'dependabot[bot]' in conjunction with other checks (e.g., repository ownership) [9][4]. workflow_dispatch When a workflow is triggered manually via workflow_dispatch, the github.actor is the user who clicked the button or triggered the event via API [1][10]. The inputs context is only available when a workflow is triggered by workflow_dispatch or is a reusable workflow [1]. Re-running a workflow_dispatch event will retain the original triggering context's privileges [1][5].
Citations:
- 1: https://docs.github.com/en/actions/reference/workflows-and-actions/contexts
- 2: https://docs.github.com/en/actions/reference/workflows-and-actions/variables
- 3: https://costops.dev/guides/control-chatops-bot-triggered-ci
- 4: https://labs.boostsecurity.io/articles/weaponizing-dependabot-pwn-request-at-its-finest/
- 5: https://github.blog/changelog/2022-07-19-differentiating-triggering-actor-from-executing-actor/
- 6: https://docs.github.com/en/code-security/reference/supply-chain-security/troubleshoot-dependabot/dependabot-on-actions
- 7: https://docs.github.com/en/code-security/reference/supply-chain-security/dependabot-on-actions
- 8: https://github.com/github/docs/blob/main/content/code-security/tutorials/secure-your-dependencies/automating-dependabot-with-github-actions.md
- 9: [BUG]:
bot-conditionsfalse positive whengithub.actoris used only to suppress follow-up bot reruns zizmorcore/zizmor#1914 - 10: https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows
🌐 Web query:
GitHub Actions triggers a workflow by Dependabot pull_request branch protection merge commit github.actor changing
💡 Result:
When GitHub Actions workflows are triggered by Dependabot, they are subject to specific security restrictions because Dependabot is treated as an external actor (similar to a pull request from a fork) [1][2][3]. Key behaviors and constraints for Dependabot-triggered workflows include: 1. Token Permissions: By default, workflows triggered by Dependabot via pull_request or push events receive a read-only GITHUB_TOKEN [1][3]. While you can elevate these permissions using the permissions key in your workflow file, this is often insufficient if the workflow also requires access to secrets [2][4]. 2. Secrets Access: Workflows triggered by Dependabot cannot access standard GitHub Actions secrets [1][2]. They only have access to Dependabot-specific secrets configured in your repository settings [1][5][3]. If your workflow requires access to repository or organization-level secrets (such as a personal access token for merging), these must be added as Dependabot secrets [1][5]. 3. Event Triggers: - pull_request: Workflows use a read-only token and have limited access to secrets [1][2][3]. - pull_request_target: This event runs in the context of the base branch and is commonly used for automation tasks like auto-merging or labeling because it provides the write permissions and access to secrets needed to perform these actions [6][7]. However, note that if the base reference of the pull request was also created by Dependabot, even pull_request_target workflows may face the same read-only and no-secrets limitations [3]. 4. Identifying the Actor: You can explicitly identify if a workflow was triggered by Dependabot using the conditional if: github.actor == 'dependabot[bot]' [1][3][7]. Conversely, you can exclude Dependabot from specific workflows using if: github.actor != 'dependabot[bot]' [1][2]. For common tasks like auto-merging Dependabot pull requests that must respect branch protection rules, the standard approach is to use a pull_request_target workflow, ensure that necessary tokens (like a PAT) are stored as Dependabot secrets, and confirm that the repository settings allow auto-merge [8][6][5][7].
Citations:
- 1: https://help.github.com/en/enterprise-server@3.15/code-security/dependabot/troubleshooting-dependabot/troubleshooting-dependabot-on-github-actions
- 2: https://docs.github.com/en/code-security/reference/supply-chain-security/troubleshoot-dependabot/dependabot-on-actions
- 3: https://docs.github.com/en/code-security/reference/supply-chain-security/dependabot-on-actions
- 4: https://github.blog/changelog/2021-10-06-github-actions-workflows-triggered-by-dependabot-prs-will-respect-permissions-key-in-workflows/
- 5: https://github.com/Abilityai/trinity/blob/5d6cd2688e8aae8e1daf1e6b2a9f85147a294beb/.github/workflows/dependabot-auto-merge.yml
- 6: chore(workflow): change pull_request event to pull_request_target AbsaOSS/version-tag-check#74
- 7: https://github.com/dependabot/fetch-metadata?tab=readme-ov-file
- 8: https://docs.github.com/en/code-security/tutorials/secure-your-dependencies/automate-dependabot-with-actions
🌐 Web query:
site:github.blog.com changelog "dependabot" "github.actor" "human push"
💡 Result:
Closest matches on the GitHub Changelog are:
- Dependabot migration to GitHub Actions — Dependabot PR jobs now run as GitHub Actions workflows, which affects workflow context/actor behavior. (github.blog)
- GitHub Actions: Workflows triggered by Dependabot PRs will run with read-only permissions — covers how Dependabot-triggered
push,pull_request, etc. are treated more like forked PRs for security. (github.blog) - GitHub Actions: Changes to permissions in workflows triggered by Dependabot — additional permissions rules for Dependabot-triggered workflows. (github.blog)
I didn’t find an exact changelog entry matching the full query text "github.actor" "human push". If you want, I can dig for the specific post about distinguishing Dependabot from human pushes in Actions.
Citations:
- 1: https://github.blog/changelog/2024-07-10-dependabot-migration-to-github-actions-for-enterprise-cloud-and-free-pro-and-teams-accounts-with-actions-enabled/?utm_source=openai
- 2: https://github.blog/changelog/2021-02-19-github-actions-workflows-triggered-by-dependabot-prs-will-run-with-read-only-permissions/?utm_source=openai
- 3: https://github.blog/changelog/2021-12-09-github-actions-changes-to-permissions-in-workflows-triggered-by-dependabot/?utm_source=openai
🌐 Web query:
GitHub Actions github.actor pull_request triggered by Dependabot branch protection merge commit
💡 Result:
In GitHub Actions, relying on github.actor to identify Dependabot for critical tasks like auto-merging pull requests is an anti-pattern that can lead to "Confused Deputy" security vulnerabilities [1][2]. The github.actor context refers to the user or bot that triggered the workflow run, not the author of the pull request [3][2]. Because github.actor reflects the last actor to interact with the repository in a way that triggers an event (e.g., pushing a commit or commenting on a PR), an attacker can manipulate this value [2][4]. For example, if a workflow is triggered by an event on a pull request, an attacker could force a synchronize event or comment on a PR to make github.actor appear as dependabot[bot] even if the PR content was modified by someone else [2][4]. To securely identify if a pull request was created by Dependabot, you should use the immutable PR metadata instead [3][4]. Specifically, check the pull request author using the following condition: if: ${{ github.event.pull_request.user.login == 'dependabot[bot]' }} This check is resistant to spoofing because it relies on the original creator of the pull request rather than the actor who most recently triggered the workflow [3][4]. Additionally, when working with Dependabot-triggered workflows: 1. Permissions: Workflows triggered by Dependabot on events like pull_request have read-only GITHUB_TOKEN permissions by default [5][6]. You must explicitly increase these permissions using the permissions key if the workflow needs to perform actions like merging [5][7]. 2. Secrets: Standard GitHub Actions secrets are not available to Dependabot-triggered workflows; you must use Dependabot secrets instead [5][6]. 3. Security: Using pull_request_target instead of pull_request can provide more flexibility but requires extreme caution, as it grants workflows access to repository secrets, potentially exposing your repository to malicious code if the PR is compromised [1][5][7]. Always validate that the PR creator is indeed Dependabot before performing sensitive operations [1][4].
Citations:
- 1: https://boostsecurityio.github.io/poutine/rules/confused_deputy_auto_merge/
- 2: https://labs.boostsecurity.io/articles/weaponizing-dependabot-pwn-request-at-its-finest/
- 3: spatie/github-actions-watcher@916493f
- 4: https://github.com/emdash-cms/emdash/blob/db2577795fa85a5866e3e637526a0c1ce60295bc/.github/workflows/dependabot-approve.yml
- 5: https://docs.github.com/en/code-security/reference/supply-chain-security/troubleshoot-dependabot/dependabot-on-actions
- 6: https://docs.github.com/en/code-security/reference/supply-chain-security/dependabot-on-actions
- 7: https://docs.github.com/en/enterprise-cloud@latest/code-security/reference/supply-chain-security/troubleshoot-dependabot/dependabot-on-actions
Check the pull request author, not the workflow actor.
A maintainer- or forker-triggered re-run changes github.actor, so this guard can become true on a Dependabot-authored PR during subsequent pull_request: synchronize runs while the PR still lacks secrets. Use the PR author for the authorship check.
Proposed fix
(github.event.pull_request.head.repo.full_name == github.repository &&
!github.event.pull_request.draft &&
- github.actor != 'dependabot[bot]')
+ github.event.pull_request.user.login != 'dependabot[bot]')📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| # Dependabot PRs run without repository secrets (GitHub policy), so the | |
| # deploy could never succeed there; skip them cleanly instead of failing. | |
| if: >- | |
| github.event_name == 'workflow_dispatch' || | |
| (github.event.pull_request.head.repo.full_name == github.repository && | |
| !github.event.pull_request.draft) | |
| !github.event.pull_request.draft && | |
| github.actor != 'dependabot[bot]') | |
| # Dependabot PRs run without repository secrets (GitHub policy), so the | |
| # deploy could never succeed there; skip them cleanly instead of failing. | |
| if: >- | |
| github.event_name == 'workflow_dispatch' || | |
| (github.event.pull_request.head.repo.full_name == github.repository && | |
| !github.event.pull_request.draft && | |
| github.event.pull_request.user.login != 'dependabot[bot]') |
Two small guards for the website preview workflow, both found in the field today:
https://claude.ai/code/session_013Qe1Vf2yvj33BVd5W1q7HB