test(ci): add build workflow to catch build errors in CI #469
Conversation
|
Warning Rate limit exceeded@MSevey has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 18 minutes and 41 seconds before requesting another review. ⌛ 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. WalkthroughA new GitHub Actions workflow file named Changes
Possibly related PRs
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 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 (
|
RollkitBot
requested review from
gupadhyaya,
tuxcanfly and
yarikbratashchuk
![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
🧹 Outside diff range and nitpick comments (2)
.github/workflows/build.yml (2)
12-18: Checkout and Node.js setup look goodThe use of latest action versions and Node.js v18 is appropriate. The caching setup with Yarn is also good.
For clarity, consider removing the comments about alternative package managers if Yarn is the intended tool for this project. If multiple package managers are supported, it might be better to use a variable to determine which one to use. For example:
- name: Setup Node uses: actions/setup-node@v4 with: node-version: 18 cache: ${{ env.PACKAGE_MANAGER }}Then define
PACKAGE_MANAGERas an environment variable at the workflow level.
1-22: Overall, the workflow achieves its main objective with room for enhancementsThis new GitHub Actions workflow successfully addresses the PR's main objective of catching build errors in CI for the VitePress site. It uses modern GitHub Actions features and has a clear, understandable structure.
To further improve the workflow:
- Consider optimizing the trigger conditions to run only when relevant files change.
- Specify a particular Ubuntu version for consistency.
- Standardize the package manager usage or use variables if multiple are supported.
- Add steps to verify the build output and store it as an artifact.
These enhancements will make the workflow more efficient, reliable, and useful for debugging purposes. Great job on implementing this crucial CI step!
|
Overview
Something broke the docs build but it was missed because we don't have an explicit CI to verify the build.
It was previously implicitly handled via the pr preview, but that workflow fails on forks so when the build broke on a fork, the CI failure was ignored.
This PR as a specific build CI that can always run so that we can make it required to merge.
TODO:
Summary by CodeRabbit