fix(ci): tighten renovate workflow event guard

[marcusrbrown]

Summary

• stop bot-authored issues.edited and pull_request.edited events from running the Renovate workflow
• keep manual dispatches, branch pushes, and successful CI-triggered workflow_run executions enabled
• make the job-level guard explicit so non-workflow_run events are no longer accepted by accident

[fro-bot]

Verdict: PASS

This fix correctly addresses a logic bug in the Renovate workflow's job-level guard that allowed bot-authored issues.edited and pull_request.edited events to bypass the bot filter.

Blocking issues

None.

Non-blocking concerns

1. branches-ignore: [main, v0] on the push trigger — This is fine for the current repo structure, but note that pushes to any branch matching v0 (e.g., `v0.x` tags) will be excluded. If semantic versioning branches like `v0.1` are ever created, they won't trigger Renovate. This appears intentional given the `v0` prefix pattern and is consistent with the existing tagging strategy.

2. The reusable workflow pinning (`bfra-me/.github/.github/workflows/renovate.yaml@bedac8bd7b81a7832ae494873da2971e5ea7a8d4 # v4.16.8`) uses a SHA + comment pattern, which is excellent. Renovate itself will handle updates via its own `customManagers` regex rules, so this is self-maintaining.

3. !contains(github.actor, '[bot]') is a substring match — This catches any actor whose name contains [bot] (e.g., renovate[bot], dependabot[bot]), which is the standard GitHub bot naming convention. This is correct and consistent with GitHub's bot identification conventions.

How the bug worked

The old condition:

(github.event.action == edited && !contains(github.actor, [bot])) ||
(github.event_name != workflow_run || github.event.workflow_run.conclusion == success)

The second disjunct (github.event_name != workflow_run) evaluated to true for every non-workflow_run event, including bot-authored issues.edited and pull_request.edited. This meant the bot filter in the first disjunct was completely bypassed — any bot editing an issue or PR would still trigger the Renovate workflow.

Example of the bug: When dependabot[bot] edited an issue, the first clause \github.event.action == 'edited' && !contains(github.actor, '[bot]')`correctly evaluated tofalse, but the second clause `github.event_name != 'workflow_run'`evaluated totrue, making the overall condition true` — running Renovate unnecessarily.

The new condition makes each event path explicit, ensuring bot-authored edits are properly gated regardless of the event type.

Missing tests

None — this is a GitHub Actions workflow YAML file. Logic verification of the guard conditions would require GitHub Actions expression evaluation, which isn't unit-testable. The PR description accurately describes the behavior change and the fix is self-documenting.

Risk assessment: LOW

• The change tightens an existing guard (reduces false positives) rather than loosening it
• No new event types are introduced — the on: triggers are unchanged
• The only behavioral change is that bot-authored issues.edited and pull_request.edited events no longer trigger the Renovate job, which is the intended behavior
• The push, workflow_dispatch, and workflow_run paths are completely unaffected
• Blast radius is limited to the Renovate workflow — no other workflows or application code are impacted

---

Run Summary

Field	Value
Event	pull_request
Repository	fro-bot/agent
Run ID	25201316050
Cache	hit
Session	ses_21e568abeffej3UKd7sfQLwCse