Skip to content

[TT-16977] fix: trigger release workflow on PR labeled event #8089

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
buger merged 1 commit into from
Apr 17, 2026
Merged

[TT-16977] fix: trigger release workflow on PR labeled event #8089

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
1 change: 1 addition & 0 deletions .github/workflows/release.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,7 @@
schedule:
- cron: "0 0 * * 1"
pull_request:
types: [opened, synchronize, reopened, labeled]

Check warning on line 19 in .github/workflows/release.yml

View check run for this annotation

probelabs / Visor: security

security Issue 

The `pull_request` trigger with the `labeled` event can be insecure. If a privileged user can be tricked into adding a label to a malicious pull request from a fork, the workflow could run with elevated permissions and access to secrets. This could allow an attacker to exfiltrate secrets or execute malicious code in a trusted context.
Raw output 
To mitigate this risk, use the `pull_request_target` event instead of `pull_request` for workflows that need to run on events like labeling. `pull_request_target` runs in the context of the base repository with access to secrets, but it checks out the base branch, not the potentially malicious head of the pull request. If you need to evaluate the PR's code, ensure you check out the PR's head commit in a secure way, for example by using `actions/checkout` with the `ref` set to `refs/pull/${{ github.event.pull_request.number }}/merge`. Additionally, add a condition to the job to only run when the specific, expected label (e.g., 'deps-reviewed') is added, to avoid running on any label change.

Check warning on line 19 in .github/workflows/release.yml

View check run for this annotation

probelabs / Visor: architecture

architecture Issue 

The workflow is configured to trigger on any pull request `labeled` event. According to the pull request description, the intent is to run the workflow only when the `deps-reviewed` label is added. The current implementation will trigger the workflow for any label addition, leading to unnecessary CI runs and resource consumption.
Raw output 
To align with the intended behavior, add a condition to the relevant job(s) in this workflow to check for the specific label when the event type is `labeled`. This will prevent the workflow from running for irrelevant label changes.

For example, you can add an `if` condition to your job(s):
```yaml
jobs:
  your-job-name:
    if: github.event_name != 'pull_request' || github.event.action != 'labeled' || github.event.label.name == 'deps-reviewed'
    runs-on: ubuntu-latest
    steps:
      ...
```
This condition ensures the job runs for all triggers other than a `pull_request` `labeled` event, and for `labeled` events, it only runs if the label name is `deps-reviewed`.

Check warning on line 19 in .github/workflows/release.yml

View check run for this annotation

probelabs / Visor: quality

performance Issue 

The `pull_request` trigger with `types: [labeled]` will cause this workflow to run every time any label is added to a pull request. This can lead to unnecessary workflow executions, consuming resources. The workflow should ideally only run when the specific `deps-reviewed` label is added, as mentioned in the pull request description.
Raw output 
Add a condition to the jobs within this workflow to ensure they only execute when the relevant label (`deps-reviewed`) is applied. For example, add an `if` condition to each job that needs to run on this event: `if: github.event.action != 'labeled' || github.event.label.name == 'deps-reviewed'`.

Check warning on line 19 in .github/workflows/release.yml

View check run for this annotation

probelabs / Visor: performance

performance Issue 

The `pull_request` trigger is configured to run on the `labeled` event for any label. This will trigger the workflow every time a label is added to a pull request. According to the pull request description, the intent is to run only for the `deps-reviewed` label. This configuration will cause unnecessary workflow runs for other labels, consuming extra CI resources.
Raw output 
To prevent unnecessary workflow runs, add a condition to the job(s) in this workflow to ensure they only run for the `deps-reviewed` label when the trigger is the `labeled` event. A condition like `if: github.event.action != 'labeled' || github.event.label.name == 'deps-reviewed'` on each job would achieve this, allowing existing triggers to function as before while restricting the new `labeled` trigger.
push:
branches:
- master
Expand Down
Loading