Repository navigation
fix(ci): remove invalid workflow references - #489
Conversation
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
🤖 CodeAnt AI — Review Status
|
Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
codeant-ai
Bot
added
the
size:XS
|
Note
|
| Layer / File(s) | Summary |
|---|---|
Workflow output and gate updates .github/workflows/ci.yml |
The detection job confirms that outputs were written to GITHUB_OUTPUT. The lint gate references needs.dep-review.result. |
Estimated code review effort: 1 (Trivial) | ~5 minutes
Suggested reviewers: copilot
🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
| Check name | Status | Explanation |
|---|---|---|
| Title check | ✅ Passed | The title clearly and concisely describes the removal of invalid CI workflow references. |
| Description check | ✅ Passed | The description explains the workflow fixes and validation performed, but omits several template sections that are not critical for this small CI-only change. |
| Docstring Coverage | ✅ Passed | No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. |
| Linked Issues check | ✅ Passed | Check skipped because no linked issues were found for this pull request. |
| Out of Scope Changes check | ✅ Passed | Check skipped because no linked issues were found for this pull request. |
✨ Finishing Touches 💡 1
🛠️ Fix failing CI checks 💡
- Create stacked PR
- Commit on current branch
🧪 Generate unit tests (beta)
- Create PR with unit tests
- Commit unit tests in branch
fix/ci-expression-gates-20260802
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
Comment @coderabbitai help to get the list of available commands.
Code Review SummaryStatus: No Issues Found | Recommendation: Merge Files Reviewed (1 file)
Reviewed by ling-3.0-flash-free · Input: 42K · Output: 5.2K · Cached: 189.1K |
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/ci.yml:
- Line 214: Update the depend-review job and aggregate gate so dependency review
action failures remain visible: remove the job-level continue-on-error, or
expose and aggregate the action step’s outcome before any step-level
continue-on-error. Ensure the aggregate status check treats a failed dependency
review as failure rather than allowing exit 0.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: ec0cc956-f2f2-427f-9158-2af161fc98c1
📒 Files selected for processing (1)
.github/workflows/ci.yml
| "typescript:${{ needs.typescript.result }}" \ | ||
| "security:${{ needs.security.result }}" \ | ||
| "dep-review:${{ needs.dependency-review.result }}" \ | ||
| "dep-review:${{ needs.dep-review.result }}" \ |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "## workflow excerpt"
wc -l .github/workflows/ci.yml
sed -n '160,230p' .github/workflows/ci.yml
echo "## relevant job declarations and aggregate references"
rg -n "dep-review|continue-on-error|needs\.dep-review|exit 1|aggregate|git diff|dependency.*review" .github/workflows/ci.ymlRepository: KooshaPari/OmniRoute
Length of output: 3128
🌐 Web query:
GitHub Actions workflow contexts needs.<job_id>.result continue-on-error failed job passes without failing workflow
💡 Result:
In GitHub Actions, setting continue-on-error: true on a job causes the job to report a status of success in the needs context, even if the job actually encountered failures [1][2]. This behavior means that any downstream jobs relying on needs.<job_id>.result == 'success' will proceed as if the upstream job succeeded [1]. While the job itself may still show a warning or failure indicator in the GitHub Actions UI depending on the specific runner version and configuration [3][4], the programmatic result exposed to the workflow context treats it as a success [1]. This is a known and long-standing behavior where continue-on-error effectively masks the failure at the job-result level [1][2]. If you need to detect the actual outcome of a job despite continue-on-error: true, you cannot rely solely on needs.<job_id>.result [1][2]. Common workarounds include: 1. Using outputs: Configure the job to set a specific output value (e.g., job-status: failure) using echo "{name}={value}" >> $GITHUB_OUTPUT if a step fails [1]. You can then check this output in downstream jobs instead of checking needs.<job_id>.result [1]. 2. Alternative logic: If the job failure is expected, ensure your workflow design does not depend on the result context to gate execution if you need precise failure detection [2]. Note that continue-on-error at the step level behaves differently, providing both outcome (the raw result of the step) and conclusion (the final result after continue-on-error is applied) [5]. However, at the job level, the needs context primarily exposes the effective result [1][2].
Citations:
- 1: needs.<job id>.result is using steps conclusion instead of outcome actions/toolkit#581
- 2:
continue-on-errorshould not returnsuccessinneeds_job_resultactions/toolkit#1739 - 3: Wrong behaviour when combining 'continue-on-error' and 'failure()' in subsequent steps actions/toolkit#1034
- 4: Wrong behaviour when combining 'continue-on-error' and 'failure()' in subsequent steps actions/toolkit#1034
- 5: https://docs.github.com/en/enterprise-server@3.18/actions/reference/workflows-and-actions/contexts
🌐 Web query:
GitHub Actions action failure continue-on-error job result cancelled needs context
💡 Result:
In GitHub Actions, the continue-on-error flag at the job level is designed to allow a workflow to proceed even if a job encounters errors, but it does not change the semantic result of that job when viewed through the needs context [1]. Key behaviors include: 1. Job Result Context: When a job is marked with continue-on-error: true, even if steps within the job fail, the job's result (accessible via needs.<job_id>.result) often reports as success [2][3][1]. This is a known limitation that can cause downstream jobs to execute unintentionally when they rely on a strict success check [3][4]. 2. Dependency Handling: By default, if a job in a needs list fails, all dependent jobs are marked as skipped and will not run [5][6]. If you intend for a downstream job to run regardless of the success or failure of a predecessor—or to specifically react to a failure—you must explicitly use a conditional check in the downstream job, such as if: always() or if: needs.<job_id>.result == 'failure' [5][6]. 3. Cancellation: When a workflow or job is cancelled, the needs.<job_id>.result will correctly report as cancelled [7][5]. Downstream jobs that depend on a cancelled job will be skipped unless they have an if condition that accounts for the cancelled status [5][6]. Recommendation: If you need to distinguish between a job that genuinely succeeded and one that failed but had continue-on-error: true enabled, do not rely solely on the job-level result [1][4]. Instead, use more granular output signals or check the specific outcomes of critical steps within the job if possible [8][1]. To avoid hidden failures, consider replacing continue-on-error with explicit if: failure() conditions in downstream jobs if you need to handle specific error recovery logic [4]. Top results: [2], [7], [1], [5]
Citations:
- 1: https://www.kenmuse.com/blog/how-to-handle-step-and-job-errors-in-github-actions/
- 2: needs.<job id>.result is using steps conclusion instead of outcome actions/toolkit#581
- 3:
continue-on-errorshould not returnsuccessinneeds_job_resultactions/toolkit#1739 - 4: https://actsense.dev/vulnerabilities/continue_on_error_critical_job/
- 5: https://adhdecode.com/articles/github-actions/github-actions-needs-dependency-jobs/
- 6: https://oneuptime.com/blog/post/2026-02-02-github-actions-job-dependencies/view
- 7: https://docs.github.com/en/actions/reference/workflows-and-actions/contexts
- 8: Wrong behaviour when combining 'continue-on-error' and 'failure()' in subsequent steps actions/toolkit#1034
🌐 Web query:
site:github.com/actions/toolkit issue 1739 continue-on-error job context result success
💡 Result:
In GitHub Actions, setting continue-on-error: true on a job causes the job's result—as reported in the needs context of subsequent jobs—to be reported as success, even if steps within that job have failed [1][2]. This behavior is a known limitation that has been tracked in multiple issues, including issue 1739 in the actions/toolkit repository [1]. Because the job result is reported as success, conditional checks in downstream jobs using needs.<job_id>.result == 'success' will evaluate to true even when the job experienced internal failures [2]. To handle this effectively: 1. Understand the difference between outcome and conclusion: A step's outcome reflects its result regardless of the continue-on-error setting, while its conclusion reflects the final status after considering that setting. 2. Use step-level outcomes for conditional logic: If you need to detect if a specific step failed despite continue-on-error being set to true, you should check the step's outcome (e.g., if: steps.<step_id>.outcome!= 'success') rather than relying on the overall job result [3][4]. 3. Job-level limitations: While you can set continue-on-error at the job level to ensure subsequent jobs in the workflow still run, the side effect is that the current job is masked as a success to the rest of the workflow [1][2]. Currently, there is no direct, native flag to make a job fail in the runner's status while simultaneously allowing it to report success to downstream needs context [1].
Citations:
- 1:
continue-on-errorshould not returnsuccessinneeds_job_resultactions/toolkit#1739 - 2: needs.<job id>.result is using steps conclusion instead of outcome actions/toolkit#581
- 3: Wrong behaviour when combining 'continue-on-error' and 'failure()' in subsequent steps actions/toolkit#1034
- 4: Wrong behaviour when combining 'continue-on-error' and 'failure()' in subsequent steps actions/toolkit#1034
🌐 Web query:
site:docs.github.com actions reference worklows and actions contexts continue-on-error job result needs.job.result
💡 Result:
In GitHub Actions, the 'needs' context and job result handling work as follows: The 'needs' context allows a job to access information about its dependencies, specifically via the 'needs.<job_id>.result' property [1][2]. This property indicates the final status of a dependent job and can be one of four values: 'success', 'failure', 'cancelled', or 'skipped' [1][2]. Regarding 'continue-on-error', it is important to distinguish between job-level and step-level behavior: 1. Job-Level 'continue-on-error': When a job is configured with 'continue-on-error: true', the job itself is considered successful even if it encounters errors [3]. This means that subsequent jobs depending on this job will see its 'needs.<job_id>.result' as 'success' [1][2]. This allows workflows to proceed even if an optional or experimental job fails [3]. 2. Step-Level 'continue-on-error': This affects individual step outcomes [2]. When a step has 'continue-on-error: true', its 'outcome' property will reflect the actual failure ('failure'), but its 'conclusion' property will be set to 'success' [2]. The overall job result is still influenced by the final state of its steps, but the use of 'continue-on-error' at the step level specifically prevents a failing step from failing the entire job [2]. If you need a downstream job to run regardless of the success or failure of its dependencies, you can use the 'always' conditional expression in the 'if' property of the dependent job [4]. This overrides the default behavior where jobs are skipped if their dependencies fail [4].
Citations:
- 1: https://docs.github.com/en/enterprise-server@3.21/actions/reference/workflows-and-actions/contexts
- 2: https://docs.github.com/en/actions/reference/workflows-and-actions/contexts
- 3: https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/run-job-variations
- 4: https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-jobs
Keep dependency review failures visible to the aggregate gate.
depend-review has job-level continue-on-error: true, so needs.dep-review.result can be success even when actions/dependency-review-action@v4 reports a failure. The aggregate gate only counts failure or cancelled, so a failed dependency review can pass with exit 0.
Remove work-flow-level continue-on-error for that job, or publish and aggregate the action step's pre-continue-on-error outcome instead.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/ci.yml at line 214, Update the depend-review job and
aggregate gate so dependency review action failures remain visible: remove the
job-level continue-on-error, or expose and aggregate the action step’s outcome
before any step-level continue-on-error. Ensure the aggregate status check
treats a failed dependency review as failure rather than allowing exit 0.
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
L17 Latency Budget ReportChecked against: budgets/rest-endpoints.yaml. |
L17 Latency Regression ReportThreshold: 10% p99 regression. |
User description
Summary
dep-reviewjob key in the aggregate gateValidation
git diff --checkpassedThis is a bounded follow-up to the merged #481/#487 main state.
CodeAnt-AI Description
Correct CI workflow checks and reporting
What Changed
Impact
✅ Reliable CI workflow execution✅ Dependency review failures block the aggregate gate✅ Clearer detection step output💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.
Summary by CodeRabbit