ci(actions): optimize github workflows#332
Conversation
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (4)
📝 WalkthroughWalkthroughMultiple GitHub Actions workflows are updated to standardize execution constraints and triggers. Changes include narrowing push branches to Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~22 minutes Possibly related PRs
Suggested labels
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
✅ Contributor ReportUser: @yacosta738
Contributor Report evaluates based on public GitHub activity. Analysis period: 2025-03-26 to 2026-03-26 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/_build-native-binaries.yml (1)
37-38: 🧹 Nitpick | 🔵 TrivialConsider adding shallow clone for consistency.
The PR objectives mention "reducing checkout history to shallow clones (
fetch-depth: 1)". Adding this here would align with the broader optimization effort and speed up checkout.⚡ Proposed optimization
- name: ✈ Checkout repository uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2 + with: + fetch-depth: 1🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/_build-native-binaries.yml around lines 37 - 38, Update the "✈ Checkout repository" GitHub Actions step to perform a shallow clone by adding the fetch-depth option to the actions/checkout step; specifically, modify the step that uses actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd (step name "✈ Checkout repository") to include with: fetch-depth: 1 so the checkout uses a shallow clone and reduces history/fetch time.
🤖 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/detekt.yml:
- Around line 25-42: Update the Detekt workflow path filters: replace the glob
pattern "*.gradle.kts" with "**/*.gradle.kts" under both the push and
pull_request "paths" arrays so nested Gradle Kotlin DSL files (e.g.,
clients/agent-runtime/build.gradle.kts and clients/web/build.gradle.kts) are
included; edit the two occurrences of the "*.gradle.kts" entry in the
.github/workflows/detekt.yml paths sections to use "**/*.gradle.kts" instead.
In @.github/workflows/pull-request-check.yml:
- Line 37: The workflow uses fetch-depth: 1 which leaves only the automatic
merge commit at HEAD so the commit-message validation step skips PR commits; fix
by either restoring the commented fetch of the target branch (the previously
commented lines that fetch the base/merge refs so PR commits are present) or set
fetch-depth to 0 (or a sufficient depth) in the checkout step so the full PR
commit history is available before running the validation script; update the
checkout step (referenced by the fetch-depth setting) accordingly so the
commit-message validator runs against the actual PR commits.
In @.github/workflows/release-please.yml:
- Around line 10-12: The workflow concurrency setting uses "cancel-in-progress:
true" which can abort in-flight release-please runs and cause missed or
inconsistent releases; update the concurrency block (the concurrency key with
group: ${{ github.workflow }}-${{ github.ref || github.run_id }}) to set
"cancel-in-progress: false" so that release-please runs are allowed to complete
for each push and changelogs/releases are not skipped or left in an inconsistent
state.
---
Outside diff comments:
In @.github/workflows/_build-native-binaries.yml:
- Around line 37-38: Update the "✈ Checkout repository" GitHub Actions step to
perform a shallow clone by adding the fetch-depth option to the actions/checkout
step; specifically, modify the step that uses
actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd (step name "✈ Checkout
repository") to include with: fetch-depth: 1 so the checkout uses a shallow
clone and reduces history/fetch time.
🪄 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: ASSERTIVE
Plan: Pro
Run ID: d69efa97-9761-499d-adf5-4197af3d72f0
📒 Files selected for processing (16)
.github/workflows/README.md.github/workflows/_build-native-binaries.yml.github/workflows/_publish.yml.github/workflows/auto-fix-lockfile.yml.github/workflows/core-check.yml.github/workflows/dependency-review.yml.github/workflows/detekt.yml.github/workflows/fix-renovate.yml.github/workflows/git-sync-labels.yml.github/workflows/lychee-links.yml.github/workflows/publish-snapshot.yml.github/workflows/pull-request-check-build-logic.yml.github/workflows/pull-request-check.yml.github/workflows/pull-request-limit.yml.github/workflows/release-please.yml.github/workflows/security-dependencies.yml
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (6)
- GitHub Check: core-checks
- GitHub Check: sonar
- GitHub Check: Scan
- GitHub Check: report / Contributor Quality Report
- GitHub Check: pr-checks
- GitHub Check: Cloudflare Pages
🧰 Additional context used
🧠 Learnings (3)
📚 Learning: 2026-02-17T12:31:17.076Z
Learnt from: CR
Repo: dallay/corvus PR: 0
File: clients/agent-runtime/AGENTS.md:0-0
Timestamp: 2026-02-17T12:31:17.076Z
Learning: Applies to clients/agent-runtime/.github/**/*.{yml,yaml} : For workflow/template-only changes, ensure YAML/template syntax validity
Applied to files:
.github/workflows/pull-request-check-build-logic.yml.github/workflows/core-check.yml.github/workflows/pull-request-limit.yml.github/workflows/auto-fix-lockfile.yml.github/workflows/security-dependencies.yml.github/workflows/fix-renovate.yml.github/workflows/detekt.yml.github/workflows/README.md
📚 Learning: 2026-02-17T12:31:17.076Z
Learnt from: CR
Repo: dallay/corvus PR: 0
File: clients/agent-runtime/AGENTS.md:0-0
Timestamp: 2026-02-17T12:31:17.076Z
Learning: Follow `.github/pull_request_template.md` and keep PR descriptions concrete with problem, change, non-goals, risk, and rollback information
Applied to files:
.github/workflows/pull-request-limit.yml
📚 Learning: 2026-02-17T07:28:38.934Z
Learnt from: CR
Repo: dallay/corvus PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-02-17T07:28:38.934Z
Learning: Applies to .agents/AGENTS.md : Document agent configurations and capabilities in AGENTS.md
Applied to files:
.github/workflows/README.md
🔇 Additional comments (20)
.github/workflows/pull-request-limit.yml (1)
29-33: Good hardening on shell argument quotingQuoting
"$PR"across allgh pr ...calls avoids shell-splitting edge cases and keeps behavior deterministic. This is a solid safety improvement with no downside..github/workflows/lychee-links.yml (1)
32-32: LGTM — shallow clone is appropriate here.Lychee only scans file contents for broken links; it doesn't need git history. Switching to
fetch-depth: 1reduces checkout time with no functional impact..github/workflows/_build-native-binaries.yml (1)
10-10: LGTM: Timeout safeguard added.The 60-minute timeout is a sensible safeguard for multi-platform Rust builds and aligns with the PR's optimization objectives.
.github/workflows/core-check.yml (1)
7-8: LGTM!Narrowing push triggers to
mainandminorreduces redundant CI runs on feature branches while preserving PR-based validation. Thepull_requesttrigger still covers feature branches adequately..github/workflows/pull-request-check.yml (1)
7-8: Push trigger narrowing looks correct for branch protection.The
pr-checksjob will still run on pushes tomainandminor, satisfying the required status checks inmain-protection.jsonandminor-protection.json. PRs continue to be validated via thepull_requesttrigger..github/workflows/pull-request-check-build-logic.yml (1)
7-8: LGTM!Branch narrowing and shallow clone are appropriate for this workflow. The Gradle build-logic checks don't require git history.
Also applies to: 43-43
.github/workflows/release-please.yml (1)
22-22: Timeout addition looks good.15 minutes is a reasonable ceiling for release-please operations.
.github/workflows/dependency-review.yml (2)
10-12: Concurrency and timeout additions look good.Grouping by PR number and setting a 10-minute timeout are sensible optimizations for this lightweight scan job.
Also applies to: 20-20
24-25: The shallow clone withfetch-depth: 1is compatible withactions/dependency-review-actionand is the standard configuration for this action. The action fetches necessary refs internally and does not depend on local git history.> Likely an incorrect or invalid review comment..github/workflows/auto-fix-lockfile.yml (1)
9-11: LGTM!Concurrency grouping, 45-minute timeout, and shallow clone are all appropriate for this lockfile maintenance workflow. The
create-pull-requestaction works correctly with shallow clones.Also applies to: 19-19, 26-26
.github/workflows/security-dependencies.yml (1)
13-18: LGTM!Good security hygiene with minimal workflow-level permissions (
contents: read) and job-level elevation only where needed. Timeouts and shallow clones are appropriate for these dependency scanning tasks.Also applies to: 24-24, 28-29, 49-49, 55-56
.github/workflows/publish-snapshot.yml (1)
9-11: Reconsidercancel-in-progress: truefor snapshot publishing.Job cancellation will interrupt in-flight artifact uploads despite
continue-on-error: trueon publishing steps (which only handles failures, not cancellation). For snapshots this is lower-risk because:
- Snapshots are idempotent (re-runs overwrite the same version)
- Maven/Gradle is the primary publish step and uses
continue-on-error: true- Release-specific uploads (npm, Docker, crates.io) are gated by
inputs.releaseand skipped for snapshotsHowever, if an upload is mid-flight during cancellation, it could be interrupted. Consider removing
cancel-in-progress: truefor publishing workflows, or document why concurrent publishes are acceptable..github/workflows/git-sync-labels.yml (2)
12-14: Good concurrency guard for duplicate runs.Line 12–14 correctly scopes concurrency and cancels stale in-flight label sync runs.
21-27: Checkout + timeout changes look right for this workload.Line 21 and Line 26 keep execution bounded and reduce clone cost while still fetching the required labels config.
.github/workflows/fix-renovate.yml (2)
9-16: Concurrency + timeout updates are solid.Line 9–11 prevents duplicate
/fix-lockruns per PR, and Line 16 adds a sensible upper bound for long lockfile updates.
78-80: Shallow checkout and env write hardening are both correct.Line 78 reduces checkout cost without affecting SHA-pinned checkout behavior, and Line 169 safely appends to
$GITHUB_ENV.Also applies to: 169-169
.github/workflows/_publish.yml (2)
48-70: Release gating for Rust setup is a good optimization.Line 48 and Line 70 avoid unnecessary toolchain resolution/setup on non-release runs.
36-36: Timeout caps are well applied across publish jobs.These limits reduce stuck-run risk and improve CI predictability.
Also applies to: 226-226, 296-296, 397-397, 434-434
.github/workflows/detekt.yml (1)
85-104: Query construction and SARIF rewrite refactor are safer now.Line 85–104 improves GraphQL readability/quoting, and Line 144–149 avoids in-place write hazards by using a temp file then atomic move.
Also applies to: 144-149
.github/workflows/README.md (1)
9-9: Docs updates are consistent with workflow behavior.These edits align the README with current triggers, shallow checkout usage, Detekt workflow scope, and corrected Makefile link.
Also applies to: 25-25, 38-43, 60-60, 151-175, 624-624
Deploying corvus with
|
| Latest commit: |
3a15631
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://4e2f70cd.corvus-42x.pages.dev |
| Branch Preview URL: | https://bart-optimize-github-actions.corvus-42x.pages.dev |
|
1 participant
This pull request introduces several improvements and refinements to the project's GitHub Actions workflows and their documentation. The main focus is on enhancing CI/CD reliability, performance, and clarity by refining workflow triggers, adding concurrency controls, optimizing fetch strategies, and updating documentation to reflect these changes. Additionally, a new Detekt static analysis workflow for Kotlin code is introduced and documented.
Workflow Triggers and Documentation Updates:
pull-request-check.ymland related CI workflows to run only on protected branches (main,minor) instead of all branches, and updated documentation to match these changes. [1] [2] [3] [4].github/workflows/README.mdto clarify the purpose and triggers of each workflow, including the new Detekt workflow, and made minor corrections to file references. [1] [2] [3]Concurrency, Timeouts, and Fetch-depth:
concurrencygroups andcancel-in-progressto most workflows to prevent duplicate runs and reduce unnecessary CI load. [1] [2] [3] [4] [5]timeout-minutesfor jobs in several workflows to ensure jobs do not hang indefinitely. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11]fetch-depth: 1) for most workflows to speed up checkouts, except where full history is needed. [1] [2] [3] [4] [5] [6] [7]Detekt Static Analysis Workflow:
detekt.ymlworkflow for Kotlin static analysis, including path-based triggers, concurrency, timeout, and documentation. [1] [2] [3] [4] [5] [6] [7]Miscellaneous Improvements:
These changes collectively improve CI/CD efficiency, maintainability, and code quality enforcement across the project.