Allow for tests to run for dependabot without need for label

[zinduolis]

Category

Core Functionality

Feature/Issue Description

Q: Please give a brief summary of your feature/fix
A: Fixes dependabot auto-merge by allowing BrowserStack tests to run automatically for dependabot[bot] PRs without requiring the safe_to_test label. Fork PRs still require the label.

Important

After merging, the Integrate Pull Request environment must be removed from Settings → Branches → Branch protection rules → master → "Require deployments to succeed". This orphaned gate from PR #3521 is what's currently blocking all dependabot merges. Once removed, tests will run and auto-merge will resume immediately.

Q: Give a technical rundown of what you have changed (if applicable)
A:

• Added opened and synchronize to pull_request_target trigger types
• Expanded job if to also allow dependabot[bot] PRs
• Made safe_to_test label removal step conditional

Test Cases

Q: Describe your test cases, what you have covered and if there are any use cases that still need addressing.
A:

• Dependabot PRs trigger BrowserStack tests automatically
• Fork PRs still require safe_to_test label
• Label removal only fires when label was actually applied

Wiki Page

N/A

[zinduolis]

Summary

This PR fixes dependabot auto-merge by allowing BrowserStack tests to run automatically for dependabot[bot] PRs without requiring the safe_to_test label. Fork PRs continue to require the label.

Changes (github_actions.yml)

1. Expanded trigger types

# Before
types: [ labeled ]

# After
types: [ labeled, opened, synchronize ]

Adding opened and synchronize ensures the workflow fires when dependabot opens a PR or pushes an update, not only when a human applies a label.

2. Expanded job if condition

# Before
if: github.event.label.name == 'safe_to_test'

# After
if: |
  github.event.label.name == 'safe_to_test' ||
  github.event.pull_request.user.login == 'dependabot[bot]'

The job now runs for either a safe_to_test label event or any event from the dependabot[bot] actor.

3. Conditional label-removal step + error handling

• Added if: github.event.label.name == 'safe_to_test' on the "Remove safe_to_test label" step so it only fires for label-triggered runs.
• Wrapped the removeLabel call in a try/catch that swallows HTTP 404 (label already removed), preventing spurious failures from race conditions.

Security Analysis

pull_request_target context: This event runs with write access and base-repo secrets. The existing safe_to_test pattern gates fork PRs properly. The key question is whether the new conditions maintain that gate.

Scenario	label.name == 'safe_to_test'	user.login == 'dependabot[bot]'	Job runs?
Fork PR opened / pushed	false (no label event)	false	No
Fork PR labeled safe_to_test	true	false	Yes
Dependabot PR opened / pushed	false	true	Yes
Dependabot PR labeled safe_to_test	true	true	Yes
Any PR, non-safe label applied	false	depends	Only if dependabot

The [bot] suffix is GitHub-reserved for GitHub App accounts. Regular users cannot impersonate dependabot[bot], so the check is safe. Fork PRs from untrusted contributors still require a maintainer to apply the safe_to_test label before secrets are exposed.

Potential Issues

1. Increased workflow trigger volume (Low impact)

Every opened/synchronize event on any PR now triggers the workflow, even though the if condition skips it for non-matching PRs. This consumes a small amount of Actions quota for the "check if condition" evaluation but is negligible in practice.

2. Double runs on dependabot PRs (Negligible)

If someone manually labels a dependabot PR with safe_to_test, the workflow runs from the labeled event while it may already be running from the opened/synchronize event. This is unlikely in practice since the whole point is to avoid labeling dependabot PRs.

3. Post-merge manual step required (Important)

The PR description notes that the Integrate Pull Request environment must be removed from Settings -> Branches -> Branch protection rules -> master -> "Require deployments to succeed". This orphaned gate from PR #3521 is what currently blocks all dependabot merges. This manual step is essential for the fix to take effect.

[zinduolis]

Workflow fix (github_actions.yml): Added a concurrency group at the job level, keyed on the PR number with cancel-in-progress: true. This ensures only one BrowserStack test runs per PR at a time, eliminating the double-run scenario.