Conversation
…pression - Add `github.event.deployment_status.state` to AllowedExpressions in pkg/constants/tool_constants.go to support deployment_status workflows - Create .github/workflows/deployment-incident-monitor.md: canonical DevOps example workflow that triggers on deployment_status events, uses skip-if-match for deduplication, expires for cleanup, and close-older-issues to keep incidents current - Compile deployment-incident-monitor.lock.yml - Update .github/aw/github-agentic-workflows.md with a new 'Deployment Incident Monitor (DevOps)' section in Common Workflow Patterns referencing the new example and explaining key features Agent-Logs-Url: https://github.com/github/gh-aw/sessions/f96a38d1-ceee-41ed-8285-2a4429518d96 Co-authored-by: gh-aw-bot <259018956+gh-aw-bot@users.noreply.github.com>
…t deployment_status.state enum values Agent-Logs-Url: https://github.com/github/gh-aw/sessions/f96a38d1-ceee-41ed-8285-2a4429518d96 Co-authored-by: gh-aw-bot <259018956+gh-aw-bot@users.noreply.github.com>
|
Hey One thing would help round this out before merge:
If you'd like a hand:
|
| --- | ||
| description: Monitors deployment failures and automatically creates deduplicated incident issues with root cause analysis. | ||
| on: | ||
| deployment_status: |
There was a problem hiding this comment.
- extend front matter support with "state" field that allows to declare the states, which then compiled into the if expression.
- also add support in the on: ... short form natural language parser
There was a problem hiding this comment.
Done in 3f33d38. Two additions were made:
1. state: field in frontmatter — deployment_status now accepts a state: property that is compiled into the activation job's if: condition automatically, with the lines commented out in the lock file:
on:
deployment_status:
state: [error, failure] # → compiled to: github.event.deployment_status.state == 'error' || ...2. Natural language shorthand — the trigger parser now handles deployment patterns:
on: "deployment failed or error" # → deployment_status trigger with state condition
on: "deployment error" # → single-state conditionThe example workflow deployment-incident-monitor.md was updated to use state: [error, failure] instead of the explicit if: condition, and the TriggerIR.Conditions are now propagated into the frontmatter if: field for all NL trigger shorthands.
… parser - Add state: [error, failure] field to deployment_status in on: section; compiler compiles it into a job if: condition automatically and comments out the state: lines from the lock file - Add natural language trigger shorthand: "deployment failed or error" compiles to deployment_status trigger with state condition - Propagate TriggerIR.Conditions into frontmatter if: field in schedule_preprocessing.go (enables all future NL triggers with conditions) - Update pkg/parser/schemas/main_workflow_schema.json to allow state: on deployment_status with enum values - Update deployment-incident-monitor.md example to use state: [error, failure] instead of explicit if: condition - Add tests for deployment trigger NL patterns in trigger_parser_test.go Agent-Logs-Url: https://github.com/github/gh-aw/sessions/ab0a0ad4-2252-4610-a09b-d50a74656b2e Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
|
Just as a heads up, I was blocked by some firewall rules while working on your feedback. Expand below for details. Warning Firewall rules blocked me from connecting to one or more addresses (expand for details)I tried to connect to the following addresses, but was blocked by firewall rules:
If you need me to access, download, or install something from one of these locations, you can either:
|
🧪 Test Quality Sentinel ReportTest Quality Score: 76/100
Test Classification DetailsView all 5 test cases
Suggestions (non-blocking)
|
There was a problem hiding this comment.
Pull request overview
Adds first-class support and canonical examples for filtering deployment_status events by deployment state, improving guidance around deployment_status/workflow_run triggers for incident automation workflows.
Changes:
- Extend schema + expression allowlist to support
on.deployment_status.statefiltering andgithub.event.deployment_status.stateexpressions. - Add compiler logic to compile
deployment_status.stateinto job-levelif:conditions and support NL shorthands like"deployment failed or error". - Add a canonical “Deployment Incident Monitor” example workflow + documentation describing the pattern.
Show a summary per file
| File | Description |
|---|---|
pkg/constants/tool_constants.go |
Allow github.event.deployment_status.state in expression allowlist. |
pkg/parser/schemas/main_workflow_schema.json |
Add on.deployment_status.state (string/array) with enum validation. |
pkg/workflow/frontmatter_extraction_yaml.go |
Generate and merge deployment_status.state conditions; comment out state: in compiled on:. |
pkg/workflow/trigger_parser.go |
Add NL trigger shorthand parsing for deployment failures/errors into deployment_status + conditions. |
pkg/workflow/schedule_preprocessing.go |
Propagate TriggerIR.Conditions from NL trigger expansion into frontmatter if:. |
pkg/workflow/trigger_parser_test.go |
Add unit tests for the new deployment NL shorthands. |
.github/workflows/deployment-incident-monitor.md |
Add canonical DevOps incident workflow using deployment_status.state. |
.github/workflows/deployment-incident-monitor.lock.yml |
Compiled workflow output showing state: compiled into job if: conditions. |
.github/aw/github-agentic-workflows.md |
Document the new canonical pattern and the state: values/shorthand. |
Copilot's findings
Tip
Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comments suppressed due to low confidence (1)
pkg/workflow/schedule_preprocessing.go:180
- When propagating TriggerIR.Conditions into frontmatter["if"], the code concatenates the existing string value directly. If the existing value is in an accepted form like "if: " or "${{ }}" (both appear elsewhere in the codebase/tests), the resulting merged condition can become syntactically invalid (e.g., "(if: always()) && (...)" or "(${{ always() }}) && (...)"), which will later break job rendering. Normalize/unwrap the existing value (and keep the stored value as a plain expression) before combining.
if existing, ok := frontmatter["if"].(string); ok && existing != "" {
frontmatter["if"] = "(" + existing + ") && (" + condition + ")"
} else {
frontmatter["if"] = condition
}
- Files reviewed: 9/9 changed files
- Comments generated: 2
| // Propagate any job-level conditions into the frontmatter if: field | ||
| if len(triggerIR.Conditions) > 0 { | ||
| condition := strings.Join(triggerIR.Conditions, " && ") | ||
| schedulePreprocessingLog.Printf("Setting if condition from trigger shorthand: %s", condition) | ||
| // Merge with any existing if condition |
There was a problem hiding this comment.
New behavior: preprocessing now derives a job-level condition from trigger shorthand and writes it into frontmatter["if"]. There are extensive tests for schedule preprocessing, but none appear to cover this condition-propagation path (including merging with an existing if). Adding unit tests here would help prevent regressions, especially around valid input forms like "if: ..." and "${{ ... }}".
This issue also appears on line 176 of the same file.
| frontmatterLog.Printf("Merging deployment_status state condition: %s", stateCondition) | ||
| if ifExpr != "" { | ||
| ifExpr = "(" + ifExpr + ") && (" + stateCondition + ")" | ||
| } else { | ||
| ifExpr = stateCondition |
There was a problem hiding this comment.
extractIfCondition() now merges an on.deployment_status.state-derived condition with the existing frontmatter if expression. If the existing if was provided as a wrapped GitHub Actions expression ("${{ ... }}"), the merge produces an invalid nested expression like "(${{ ... }}) && (...)". Consider unwrapping both sides (strip "${{ }}" and any leading "if: ") before combining, and return a single valid expression string.
…pilation Draft ADR generated by the Design Decision Gate workflow for PR #28549. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Commit pushed:
|
🏗️ Design Decision Gate — ADR RequiredThis PR makes significant changes to core business logic (232 new lines in business logic directories, threshold: 100) but does not have a linked Architecture Decision Record (ADR). AI has analyzed the PR diff and generated a draft ADR to help you get started: 📄 Draft ADR: What to do next
Once an ADR is linked in the PR body, this gate will re-run and verify the implementation matches the decision. Draft ADR SummaryThe draft ADR captures the following:
Why ADRs Matter
ADRs create a searchable, permanent record of why the codebase looks the way it does. Future contributors (and your future self) will thank you. 📋 Michael Nygard ADR Format ReferenceAn ADR must contain these four sections to be considered complete:
All ADRs are stored in
References: §24955643779
|
|
@copilot review all comments |
…n propagation tests
- In extractIfCondition(): strip ${{ }} wrapper from existing frontmatter
if: value before merging with deployment_status.state condition, preventing
invalid nested expressions like (${{ expr }}) && (...)
- In schedule_preprocessing.go: strip ${{ }} wrapper from existing if:
value before merging with TriggerIR.Conditions
- Keep extractExpressionFromIfString() unchanged (used for custom jobs
where ${{ }} must be preserved as-is for GitHub Actions)
- Add TestTriggerShorthandConditionPropagation tests covering: bare if,
${{ }}-wrapped if, and multi-state deployment trigger scenarios
Agent-Logs-Url: https://github.com/github/gh-aw/sessions/f74cc100-16fb-43b2-a216-d436931d533b
Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
Both review comments addressed in 71dd7ab:
Warning Firewall rules blocked me from connecting to one or more addresses (expand for details)I tried to connect to the following addresses, but was blocked by firewall rules:
If you need me to access, download, or install something from one of these locations, you can either:
|
|
…ent context - Wrap state condition with `github.event_name != 'deployment_status' || (...)` so workflows combining deployment_status + workflow_dispatch work correctly: workflow_dispatch triggers pass through while deployment_status events are still filtered by state - Add `deployment_state` field to `buildAwContext()` (aw_context.cjs): captures `payload.deployment_status.state` when event is deployment_status, empty string otherwise — propagated to child workflows via aw_context for workflow_call support - Add `deployment_state` to `generate_aw_info.cjs` awInfo so the primary workflow's agent context includes the triggering state - Add `github.event.deployment_status.state` to JS ALLOWED_EXPRESSIONS in runtime_import.cjs (was in Go constants but missing from JS list) - Update trigger_parser_test.go and schedule_preprocessing_test.go to expect the new guarded condition format Agent-Logs-Url: https://github.com/github/gh-aw/sessions/724d18f3-0d89-46d4-9474-c59fcaf090af Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
Done in f81c851:
Warning Firewall rules blocked me from connecting to one or more addresses (expand for details)I tried to connect to the following addresses, but was blocked by firewall rules:
If you need me to access, download, or install something from one of these locations, you can either:
|
|
@copilot store in otlp otel attributes |
Add gh-aw.deployment.state attribute to both the setup and conclusion OTLP
spans in send_otlp_span.cjs. The value is resolved from:
1. GH_AW_GITHUB_EVENT_DEPLOYMENT_STATUS_STATE env var (set from
${{ github.event.deployment_status.state }} in the compiled workflow)
2. awInfo.deployment_state (populated by generate_aw_info.cjs for primary
workflows triggered by deployment_status events)
3. awInfo.context.deployment_state (propagated via aw_context for called
workflows)
Agent-Logs-Url: https://github.com/github/gh-aw/sessions/7f488fa9-ba2c-4c94-808f-db26d895a6b8
Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
Done in f7c3d40.
Warning Firewall rules blocked me from connecting to one or more addresses (expand for details)I tried to connect to the following addresses, but was blocked by firewall rules:
If you need me to access, download, or install something from one of these locations, you can either:
|
Add definition for the deployment_status trigger, including the state filter field introduced in #28549. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
- Add deployment_status trigger section to triggers.md (from #28549) - Add deployment state filter (state:) and NL shorthands - Add deployment incident monitor example - Update Playwright visual regression example with dev server setup pattern (from #28550) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
deployment_statusandworkflow_runtriggers are underrepresented in examples, causing agents to default to suboptimal triggers for DevOps incident automation. This adds a canonical compilable example demonstrating the full pattern, along with first-class compiler support for filtering deployment states.Changes
pkg/constants/tool_constants.go— Addsgithub.event.deployment_status.statetoAllowedExpressions. It's an enum-like field (not user text), analogous to the already-allowedgithub.event.issue.state.pkg/parser/schemas/main_workflow_schema.json— Addsstate:property to thedeployment_statustrigger object with an enum of valid state values (error,failure,pending,success,inactive,in_progress,queued,waiting).pkg/workflow/frontmatter_extraction_yaml.go— NewextractDeploymentStatusStateCondition()readson.deployment_status.state(string or array) and generates a guarded GitHub Actions expression merged into the jobif:condition. The generated condition is wrapped withgithub.event_name != 'deployment_status' || (...)so that other combined triggers (e.g.workflow_dispatch) are not blocked.${{ }}wrappers are stripped from any existingif:value before merging to prevent invalid nested expressions.pkg/workflow/trigger_parser.go— NewparseDeploymentTrigger()handles natural-language deployment shorthands with the sameevent_nameguard:"deployment failed"→deployment_statustrigger with guardedstate == 'failure'condition"deployment error"→ guardedstate == 'error'condition"deployment failed or error"→ guarded combined OR conditionpkg/workflow/schedule_preprocessing.go—TriggerIR.Conditionsare now propagated into the frontmatterif:field after NL trigger expansion, enabling all future NL trigger shorthands that produce conditions.${{ }}wrappers are stripped from any existingif:value before merging.pkg/workflow/schedule_preprocessing_test.go— AddsTestTriggerShorthandConditionPropagationcovering the condition-propagation path: single-state triggers, multi-state triggers, merging with a bareif:, and merging with a${{ }}-wrappedif:.actions/setup/js/aw_context.cjs—buildAwContext()now includes adeployment_statefield populated frompayload.deployment_status.statewhen the triggering event isdeployment_status(empty string otherwise). This propagates the state to child workflows viaaw_contextforworkflow_callsupport.actions/setup/js/generate_aw_info.cjs— Addsdeployment_stateto theawInfoobject written toaw_info.jsonso the agent in the primary workflow has the triggering state available in its context.actions/setup/js/runtime_import.cjs— Addsgithub.event.deployment_status.statetoALLOWED_EXPRESSIONS(was in Go constants but missing from the JS list).actions/setup/js/send_otlp_span.cjs— Addsgh-aw.deployment.stateas an attribute to both the setup and conclusion OTLP spans. The value is resolved in priority order:GH_AW_GITHUB_EVENT_DEPLOYMENT_STATUS_STATEenv var (set from${{ github.event.deployment_status.state }}in the compiled workflow),awInfo.deployment_state(for primary workflows), andawInfo.context.deployment_state(propagated viaaw_contextfor called workflows)..github/workflows/deployment-incident-monitor.md— New canonical DevOps example using the newstate: [error, failure]syntax:deployment_status: state: [error, failure]compiled into a guarded jobif:conditionskip-if-matchdeduplication — skips if an open incident issue already existsexpires: 7d+close-older-issues: truefor automatic incident hygienetoolsets: [repos, actions]for root cause analysis (commit history + workflow logs)deployments: readpermission (required for the event payload).github/aw/github-agentic-workflows.md— Adds a "Deployment Incident Monitor (DevOps)" section in Common Workflow Patterns explaining each design decision, including both thestate:field and the NL shorthand.The same result can also be achieved with the natural language shorthand: