ci: create fallback for tj-actions/changed-files#1146
Conversation
WalkthroughThe Changes
Sequence Diagram(s)sequenceDiagram
participant GitHub Actions
participant check-changes job
participant changed-files step
participant fallback step
participant build job
GitHub Actions->>check-changes job: Start workflow
check-changes job->>changed-files step: Detect changed files (continue-on-error)
alt changed-files step succeeds
changed-files step->>check-changes job: Set outputs (should-build/hlsl-should-build)
else changed-files step fails
fallback step->>check-changes job: Set outputs to true (force build)
end
check-changes job->>build job: Pass outputs (should-build/hlsl-should-build)
build job->>GitHub Actions: Run build if outputs are true
Possibly related PRs
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:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. 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
Documentation and Community
|
There was a problem hiding this comment.
Pull Request Overview
This PR introduces a fallback mechanism for tj-actions/changed-files in the CI workflow to ensure builds are triggered even if file-change detection fails.
- Updates the build outputs conditions to include a failure check on the changed-files step
- Adds a step to fetch PR head and base commits
- Implements a fallback step to set outputs to true when the changed-files step fails
Comments suppressed due to low confidence (3)
.github/workflows/build.yaml:39
- Ensure that including 'steps.changed-files.conclusion == 'failure'' in the output condition aligns with the intended behavior for triggering builds when file-change detection fails, and consider adding a comment to clarify this fallback logic.
should-build: ${{ steps.changed-files.outputs.build_any_changed == 'true' || steps.changed-files.outputs.cpp_any_changed == 'true' || steps.changed-files.conclusion == 'failure' }}
.github/workflows/build.yaml:82
- Consider adding inline comments explaining the rationale behind the fallback step to help maintainers understand its purpose in the CI pipeline.
- name: Fallback - Set outputs if changed-files failed
.github/workflows/build.yaml:55
- Adding a brief comment here to explain that 'continue-on-error: true' is used intentionally to allow the fallback mechanism to trigger in case of failure would improve clarity.
continue-on-error: true
![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.yaml (1)
82-87: Fallback step enforces build on detection failure
This fallback sets both outputs totruewhenever change detection fails, guaranteeing downstream jobs run.Consider scoping the fallback more narrowly by using
if: steps.changed-files.conclusion == 'failure'instead of the genericfailure()guard.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/build.yaml(2 hunks)
🔇 Additional comments (4)
.github/workflows/build.yaml (4)
39-40: Include failure of change detection as build trigger
Extendingshould-buildandhlsl-should-buildto fire whensteps.changed-files.conclusion == 'failure'ensures the build proceeds even if the change detector errors out.
45-45: Providetokenfor authenticated checkout
Explicitly supplying${{ secrets.GITHUB_TOKEN }}guarantees proper access to PR refs during checkout.
47-51: Fetch PR head and base refs explicitly
This step ensures both the PR head and base commits are available for diffing, eliminating reliance on implicit fetch behavior.
55-55: Continue-on-error for change detection
Allowing thechanged-filesstep to continue on error prevents the entire job from failing if file-change detection encounters an issue.
Summary by CodeRabbit