feat(triggers): Add environment-aware trigger configuration#113
Conversation
Scope triggers to `local` (CLI) or `github` (Action) via an `environments` field in warden.toml. Omitting the field preserves current behavior (runs everywhere). No detection logic needed since the CLI and Action are already separate entry points that hardcode their environment. Adds code-simplifier trigger from sentry-skills, scoped to local only. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
| /** | ||
| * Check if a trigger matches the given event context. | ||
| */ | ||
| export function matchTrigger(trigger: Trigger, context: EventContext): boolean { | ||
| export function matchTrigger(trigger: Trigger, context: EventContext, environment?: WardenEnvironment): boolean { | ||
| if (environment && trigger.environments && !trigger.environments.includes(environment)) { | ||
| return false; | ||
| } | ||
|
|
||
| if (trigger.event !== context.eventType) { | ||
| return false; | ||
| } |
There was a problem hiding this comment.
Bug: The schedule workflow ignores the environments filter on triggers because it doesn't use the matchTrigger function, causing them to run in unintended environments.
Severity: MEDIUM
Suggested Fix
Modify the schedule workflow in src/action/workflow/schedule.ts to use the matchTrigger function for filtering triggers. Pass the appropriate environment context (e.g., 'github') to matchTrigger to ensure it correctly evaluates the environments field, aligning its behavior with other workflows.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: src/triggers/matcher.ts#L73-L83
Potential issue: The schedule workflow in `src/action/workflow/schedule.ts` filters
triggers only by their event type (`t.event === 'schedule'`) and does not use the
`matchTrigger` function. The `matchTrigger` function is responsible for applying
environment-based filtering. Consequently, if a user defines a schedule trigger with
`environments: ["local"]`, intending for it to run only via the CLI, it will still
execute in the GitHub Actions environment. This behavior is inconsistent with how pull
request and push triggers are handled, which correctly use `matchTrigger` to respect the
specified environment.
Did we get this right? 👍 / 👎 to inform future reviews.
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.
| export function matchTrigger(trigger: Trigger, context: EventContext, environment?: WardenEnvironment): boolean { | ||
| if (environment && trigger.environments && !trigger.environments.includes(environment)) { | ||
| return false; | ||
| } |
There was a problem hiding this comment.
Environment check bypassed when parameter not provided
Low Severity
The environment filtering logic allows triggers with explicit environments restrictions (like ['local']) to match even when the environment parameter is not provided. The condition environment && trigger.environments && ... short-circuits when environment is undefined, skipping the environment check entirely. Since matchTrigger is part of the public API, external callers that don't pass the environment parameter will see environment-restricted triggers match unexpectedly. A safer condition would be: trigger.environments && (!environment || !trigger.environments.includes(environment)).
Additional Locations (1)
1 participant
Add an
environmentsfield to triggers inwarden.tomlso users can scopetriggers to
local(CLI) orgithub(Action) runs.Omitting
environmentskeeps current behavior (runs everywhere). Theenvironment is implicit from the entry point: CLI hardcodes
"local",Action hardcodes
"github". No detection logic, no flags, no env vars.Also adds a
code-simplifiertrigger from sentry-skills scoped to localonly, since it's useful during development but not needed in CI.