Check Storybook build on CI for PRs #68466
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mirka
added
[Type] Automated Testing
This was referenced Jan 2, 2025
|
Size Change: -18 B (0%) Total Size: 1.84 MB
ℹ️ View Unchanged
|
tyxla
reviewed
Jan 2, 2025
| uses: ./.github/setup-node | ||
|
|
||
| - name: Build Storybook | ||
| run: npm run storybook:build |
There was a problem hiding this comment.
🤔 does it make sense to run the regular build command here though? We don't really need the built assets, right?
There's a --smoke-test feature we could use for this purpose:
Furthermore, for such purposes, we should likely utilize --ci, which skips any interactive prompts:
I'd suggest we introduce a new smoke test command and we use it here.
Its package.json script entry would look roughly like this (untested):
"storybook:smoke-test": "storybook dev -c ./storybook --ci --smoke-test"
WDYT?
There was a problem hiding this comment.
I saw this in the original PR but leaned toward build for a couple reasons:
- What we most want to prevent is the public Storybook workflow failing on trunk. There is a chance that the dev build succeeds but the prod build doesn't.
- At least when running
timecomparisons locally, there is no substantial wall-clock difference betweendev --ci --smoke-testandbuild, even though the total CPU time is clearly different (apparentlybuildis better parallelized). The only significant difference was in the failing case, wheredev --ci --smoke-testwas actually 1 minute slower in wall-clock time due to some weird hanging between the error being logged and the process exiting. - Using
devrequires a new test command (and possibly an additionalprecommand) in package.json.
So all in all it seems to me like using build is simpler and good enough, but no strong opinion. Thoughts?
There was a problem hiding this comment.
There is a chance that the dev build succeeds but the prod build doesn't.
Could you elaborate on that? Under what circumstances would it happen?
What's more important is that it's surprising that the smoke test is slower! In my tests against v7 (in another repo, though), that wasn't the case. If the regular build command is faster, I don't see a good reason not to go with it 👍
|
Flaky tests detected in e3ed320. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/12584968343
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
Adds a CI check on PRs to ensure that the Storybook builds without errors.
Why?
To prevent Storybook-breaking changes (like #68419 (comment)) from being merged into trunk.
Testing Instructions
✅ The CI check passes on a working build (4c12233)
✅ The CI check fails on a broken build (fdf8121)