Skip to content

ci(website): preview skips Dependabot PRs and fires on ready_for_review #5454

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
mmabrouk merged 1 commit into from
Jul 23, 2026
+5 −2
Merged

ci(website): preview skips Dependabot PRs and fires on ready_for_review #5454

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 5 additions & 2 deletions .github/workflows/15-website-preview.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@ name: "15 - website preview"

on:
pull_request:
types: [opened, synchronize, reopened]
types: [opened, synchronize, reopened, ready_for_review]
paths:
- 'website/**'
- '.github/workflows/15-website-preview.yml'
Expand Down Expand Up @@ -30,10 +30,13 @@ jobs:
name: Build and deploy preview
runs-on: ubuntu-latest
# Fork PRs get no secrets: skip when the head repo is not this repo.
# 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]')
Comment on lines +33 to +39

@coderabbitai coderabbitai Bot Jul 22, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 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 || true

Repository: 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:

🌐 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:

🌐 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:

🌐 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:

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.

Suggested change
# 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]')

env:
PR_NUMBER: ${{ github.event.pull_request.number || inputs.pr_number }}
steps:
Expand Down
Loading