chore(ci): binaries build continue-on-error when release #6865
Conversation
…ild matrix, else defaults to false
WalkthroughThe changes update the GitHub Actions workflow for building binaries. The workflow now sets a new environment variable ( Changes
Sequence Diagram(s)sequenceDiagram
participant W as Workflow Runner
participant B as Builds Job
participant C as Condition Evaluator
W->>B: Trigger build process
B->>C: Evaluate `continue-on-error` condition
C-->>B: Check if `github.ref` starts with "refs/tags/" or `matrix.best_effort` is true
alt Condition Met
B->>W: Continue build (allow errors)
else Condition Not Met
B->>W: Fail build on errors
end
Suggested reviewers
Poem
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
leet4tari
changed the title
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
.github/workflows/build_binaries.yml (1)
41-41: New Environment Variable AdditionThe addition of
RUSTUP_PERMIT_COPY_RENAME: trueon line 41 clearly documents that the Rust toolchain is being granted permission to perform copy/rename operations—likely to work around issues seen during the build. Please ensure that this change is accompanied by internal documentation or comments explaining why this flag was introduced and under which circumstances it is needed.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/build_binaries.yml(2 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (6)
- GitHub Check: test (mainnet, stagenet)
- GitHub Check: test (nextnet, nextnet)
- GitHub Check: cargo check with stable
- GitHub Check: Cucumber tests / FFI
- GitHub Check: ci
- GitHub Check: Cucumber tests / Base Layer
🔇 Additional comments (1)
.github/workflows/build_binaries.yml (1)
100-100: Refined Continue-On-Error ConditionThe updated expression for the
continue-on-errorproperty now evaluates to true if the build is triggered by a tag (indicating a release) or if the build matrix explicitly setsbest_effortto true. This refinement aligns with the PR objective of allowing release builds or explicitly-marked best-effort builds to proceed even on errors, while defaulting to a strict failure in other cases.
Please verify that:
- The condition correctly distinguishes release builds via
startsWith(github.ref, 'refs/tags/').matrix.builds.best_effortis reliably set in the build matrix when you expect a best effort build.
Overall, the logic appears clear and appropriate for the intended behavior.
Test Results (CI) 3 files 129 suites 35m 43s ⏱️ Results for commit 93d8239. |
Test Results (Integration tests) 2 files 11 suites 30m 10s ⏱️ For more details on these failures, see this check. Results for commit 93d8239. |
Description
continue-on-error when release or set in build matrix, else defaults to false
Motivation and Context
Make release happen no matter build status
Summary by CodeRabbit