Conversation
Switch example workflow trigger to status/check_run failures and add an updated workflow source copy under github/workflows for maintainers to relocate into .github/workflows. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
📝 WalkthroughWalkthroughThe pr-buildkite-detective workflow trigger is changed from listening to GitHub Changes
Sequence DiagramsequenceDiagram
participant GitHub as GitHub Events
participant Workflow as gh-aw-pr-buildkite-detective
participant GHAPI as GitHub API
participant Buildkite as Buildkite API
GitHub->>Workflow: status or check_run event (failure)
activate Workflow
Workflow->>Workflow: Step 1: Extract failed commit SHA
Workflow->>GHAPI: List open PRs, match head.sha
GHAPI-->>Workflow: PR details with branches
Workflow->>Workflow: Step 2: Resolve failed build from commit SHA
Workflow->>Buildkite: Query builds for commit SHA
Buildkite-->>Workflow: Build details
Workflow->>Workflow: Step 3: Collect failure evidence
Workflow->>Buildkite: Fetch full job logs & annotations
Buildkite-->>Workflow: Logs & pipeline data
Workflow->>Workflow: Step 4: Retain author & fork status
deactivate Workflow
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~22 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/gh-aw-pr-buildkite-detective.md:
- Around line 102-105: The chained &&/|| expressions using github.event_name,
github.event.id and github.event.check_run.* are fragile because GitHub Actions
expressions lack a ternary operator and can mis-evaluate when properties are
undefined or falsy; refactor to remove the dual-path inline logic by handling
each event type in separate conditional steps or jobs (use job/step-level if on
github.event_name == 'status' and github.event_name == 'check_run') or create
distinct workflows for each trigger so you can directly reference
github.event.id, github.event.state, github.event.sha for status events and
github.event.check_run.id, github.event.check_run.conclusion,
github.event.check_run.head_sha for check_run events instead of the current
fallback expressions.
In @.github/workflows/trigger-pr-buildkite-detective.yml:
- Around line 19-20: The existing workflow condition matches any failing
status/check_run events (github.event_name == 'status' && github.event.state ==
'failure') || (github.event_name == 'check_run' &&
github.event.check_run.conclusion == 'failure'); tighten it to only trigger for
Buildkite-originated events by adding a Buildkite actor/sender guard (e.g.
require github.actor == 'buildkite' or the corresponding sender field) to both
branches of the boolean expression so the condition becomes something like
(github.event_name == 'status' && github.event.state == 'failure' &&
github.actor == 'buildkite') || (github.event_name == 'check_run' &&
github.event.check_run.conclusion == 'failure' && github.actor == 'buildkite');
update the conditional in the workflow to include this guard.
ℹ️ Review info
Configuration used: Repository UI (base), Organization UI (inherited)
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
.github/workflows/gh-aw-pr-buildkite-detective.md.github/workflows/trigger-pr-buildkite-detective.yml
| - **Event Name**: ${{ github.event_name }} | ||
| - **Event ID**: ${{ github.event_name == 'status' && github.event.id || github.event.check_run.id }} | ||
| - **Failure State**: ${{ github.event_name == 'status' && github.event.state || github.event.check_run.conclusion }} | ||
| - **Commit SHA**: ${{ github.event_name == 'status' && github.event.sha || github.event.check_run.head_sha }} |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
GitHub Actions expressions syntax operators && || ternary official documentation
💡 Result:
- Official operator list (GitHub Actions expressions): GitHub documents these operators:
!, comparison ops (< <= > >= == !=), logical&&(and) and||(or), plus grouping/index/property (( ),[ ],.). [1] - Ternary (
cond ? a : b) support: GitHub Actions expression syntax does not include a ternary operator in the official operator list. [1] A long-running feature request explicitly asks for ternary/conditional support, indicating it’s not currently available. [2] - Common “ternary-like” workaround (uses documented operators):
${{ condition && 'trueValue' || 'falseValue' }}(works as long as'trueValue'is truthy). [1]
Sources
[1] GitHub Docs — Evaluate expressions in workflows and actions (Operators table) (docs.github.com)
[2] GitHub actions/runner issue #409 — Conditional operator or function for expression syntax (github.com)
Citations:
- 1: https://docs.github.com/actions/reference/workflows-and-actions/expressions
- 2: Conditional operator or function for expression syntax actions/runner#409
Reconsider the proposed alternative—ternary operators are not supported in GitHub Actions expressions.
The chained && and || operators in these expressions are officially documented and the standard workaround pattern for conditional logic in GitHub Actions. However, your underlying concerns about edge cases are valid:
- Undefined property access: Accessing
github.event.idwhen the event is'check_run'(where this property doesn't exist) relies on GitHub's handling of undefined properties. - Falsy value handling: If
github.event.idexists but is falsy (0, empty string), the expression will incorrectly fall back togithub.event.check_run.id.
The ternary operator (? :) is not supported in GitHub Actions expressions—this is a long-running open feature request. Instead, consider:
- Use conditional job-level
ifstatements to process each event type separately - Restructure the workflow to only trigger on a single event type, avoiding the dual-path logic
- Add explicit property existence checks if GitHub Actions provides them
🧰 Tools
🪛 LanguageTool
[uncategorized] ~102-~102: The official name of this software platform is spelled with a capital “H”.
Context: ...hub.repository }} - Event Name: ${{ github.event_name }} - Event ID: ${{ githu...
(GITHUB)
[uncategorized] ~103-~103: The official name of this software platform is spelled with a capital “H”.
Context: ...ithub.event_name }} - Event ID: ${{ github.event_name == 'status' && github.event....
(GITHUB)
[uncategorized] ~103-~103: The official name of this software platform is spelled with a capital “H”.
Context: ...*: ${{ github.event_name == 'status' && github.event.id || github.event.check_run.id }...
(GITHUB)
[uncategorized] ~103-~103: The official name of this software platform is spelled with a capital “H”.
Context: ..._name == 'status' && github.event.id || github.event.check_run.id }} - **Failure State...
(GITHUB)
[uncategorized] ~104-~104: The official name of this software platform is spelled with a capital “H”.
Context: ...heck_run.id }} - Failure State: ${{ github.event_name == 'status' && github.event....
(GITHUB)
[uncategorized] ~104-~104: The official name of this software platform is spelled with a capital “H”.
Context: ...*: ${{ github.event_name == 'status' && github.event.state || github.event.check_run.c...
(GITHUB)
[uncategorized] ~104-~104: The official name of this software platform is spelled with a capital “H”.
Context: ...me == 'status' && github.event.state || github.event.check_run.conclusion }} - **Commi...
(GITHUB)
[uncategorized] ~105-~105: The official name of this software platform is spelled with a capital “H”.
Context: ...run.conclusion }} - Commit SHA: ${{ github.event_name == 'status' && github.event....
(GITHUB)
[uncategorized] ~105-~105: The official name of this software platform is spelled with a capital “H”.
Context: ...*: ${{ github.event_name == 'status' && github.event.sha || github.event.check_run.hea...
(GITHUB)
[uncategorized] ~105-~105: The official name of this software platform is spelled with a capital “H”.
Context: ...name == 'status' && github.event.sha || github.event.check_run.head_sha }} - **Buildki...
(GITHUB)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/gh-aw-pr-buildkite-detective.md around lines 102 - 105,
The chained &&/|| expressions using github.event_name, github.event.id and
github.event.check_run.* are fragile because GitHub Actions expressions lack a
ternary operator and can mis-evaluate when properties are undefined or falsy;
refactor to remove the dual-path inline logic by handling each event type in
separate conditional steps or jobs (use job/step-level if on github.event_name
== 'status' and github.event_name == 'check_run') or create distinct workflows
for each trigger so you can directly reference github.event.id,
github.event.state, github.event.sha for status events and
github.event.check_run.id, github.event.check_run.conclusion,
github.event.check_run.head_sha for check_run events instead of the current
fallback expressions.
| (github.event_name == 'status' && github.event.state == 'failure') || | ||
| (github.event_name == 'check_run' && github.event.check_run.conclusion == 'failure') |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n .github/workflows/trigger-pr-buildkite-detective.ymlRepository: elastic/ai-github-actions
Length of output: 1206
🏁 Script executed:
# Find and read the downstream workflow
fd 'gh-aw-pr-buildkite-detective.lock.yml' --exec head -100 {}
echo "---- Search for Buildkite origin guards in all related files ----"
rg -n "context|app\.slug|buildkite" .github/workflows/ gh-agent-workflows/ | head -50Repository: elastic/ai-github-actions
Length of output: 6752
🏁 Script executed:
# Find the downstream workflow
find . -name "gh-aw-pr-buildkite-detective.lock.yml" -type f -exec cat -n {} \;
echo "---- Source example.yml ----"
cat -n gh-agent-workflows/pr-buildkite-detective/example.ymlRepository: elastic/ai-github-actions
Length of output: 50381
🏁 Script executed:
# Search for the pre_activation job and Buildkite origin checks
grep -n "pre_activation\|buildkite\|app\.slug\|status\.context" .github/workflows/gh-aw-pr-buildkite-detective.lock.yml | head -20
# Also check the source configuration
grep -rn "buildkite\|app\.slug\|status\.context" gh-agent-workflows/pr-buildkite-detective/Repository: elastic/ai-github-actions
Length of output: 12962
🏁 Script executed:
# Search for pre_activation job definition in trigger-pr-buildkite-detective.yml
sed -n '/^ pre_activation:/,/^ [a-z]/p' .github/workflows/trigger-pr-buildkite-detective.yml
# If not found, check if it's in a different location
grep -A 50 "pre_activation:" .github/workflows/trigger-pr-buildkite-detective.ymlRepository: elastic/ai-github-actions
Length of output: 51
🏁 Script executed:
# Read the full trigger workflow to see if there's a pre_activation job
cat .github/workflows/trigger-pr-buildkite-detective.ymlRepository: elastic/ai-github-actions
Length of output: 1017
🏁 Script executed:
# Extract the pre_activation job from the reusable workflow
grep -n "^ pre_activation:" .github/workflows/gh-aw-pr-buildkite-detective.lock.yml
# Get more context around it
sed -n '/^ pre_activation:/,/^ [a-zA-Z]/p' .github/workflows/gh-aw-pr-buildkite-detective.lock.yml | head -100Repository: elastic/ai-github-actions
Length of output: 1085
Scope failure filter to Buildkite-originated events.
At lines 19-20, this condition matches all failing status/check_run events, not just Buildkite. The downstream pre_activation job filters only by user role, not event origin. Add Buildkite-source guards to prevent false-positive detective runs from unrelated CI checks.
Suggested condition update
if: >-
- (github.event_name == 'status' && github.event.state == 'failure') ||
- (github.event_name == 'check_run' && github.event.check_run.conclusion == 'failure')
+ (github.event_name == 'status' &&
+ github.event.state == 'failure' &&
+ startsWith(github.event.context, 'buildkite/')) ||
+ (github.event_name == 'check_run' &&
+ github.event.check_run.conclusion == 'failure' &&
+ github.event.check_run.app.slug == 'buildkite')📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| (github.event_name == 'status' && github.event.state == 'failure') || | |
| (github.event_name == 'check_run' && github.event.check_run.conclusion == 'failure') | |
| (github.event_name == 'status' && | |
| github.event.state == 'failure' && | |
| startsWith(github.event.context, 'buildkite/')) || | |
| (github.event_name == 'check_run' && | |
| github.event.check_run.conclusion == 'failure' && | |
| github.event.check_run.app.slug == 'buildkite') |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/trigger-pr-buildkite-detective.yml around lines 19 - 20,
The existing workflow condition matches any failing status/check_run events
(github.event_name == 'status' && github.event.state == 'failure') ||
(github.event_name == 'check_run' && github.event.check_run.conclusion ==
'failure'); tighten it to only trigger for Buildkite-originated events by adding
a Buildkite actor/sender guard (e.g. require github.actor == 'buildkite' or the
corresponding sender field) to both branches of the boolean expression so the
condition becomes something like (github.event_name == 'status' &&
github.event.state == 'failure' && github.actor == 'buildkite') ||
(github.event_name == 'check_run' && github.event.check_run.conclusion ==
'failure' && github.actor == 'buildkite'); update the conditional in the
workflow to include this guard.
There was a problem hiding this comment.
Verdict: approve. I found no actionable issues in this diff.
What is this? | From workflow: PR Review
Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
Summary
This updates PR Buildkite Detective to trigger on failing GitHub commit statuses/check runs (how Buildkite reports results) instead of
workflow_run.What changed
.github/workflows/trigger-pr-buildkite-detective.ymlstatusandcheck_runevents..github/workflows/gh-aw-pr-buildkite-detective.md$\{\{ github.run_id }}.statusvscheck_run) for event ID, failure state, and commit SHA.head.shafrom the failed commit SHA.gh-agent-workflows/pr-buildkite-detective/example.ymlstatus/check_run.gh-agent-workflows/pr-buildkite-detective/README.mdValidation
git diff --stat 5a7d373bd61dbc45cc5293e4e4b14f8207e08ba8..00d02f330f17058602add8d711fca7b568afebc0confirms only the workflow/docs files above were changed.Fixes #421