Check Storybook build on CI for PRs #68466
Merged
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 👍
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?
Nothing serious, I'm just thinking of code paths in the build process that involve process.env.NODE_ENV conditionals.
|
Flaky tests detected in 9233cc9. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/12627496313
|
This reverts commit fdf8121.
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
t-hamano
approved these changes
Jan 7, 2025
| jobs: | ||
| check: | ||
| runs-on: ubuntu-latest | ||
| if: ${{ github.repository == 'WordPress/gutenberg' }} |
There was a problem hiding this comment.
Suggested change
| if: ${{ github.repository == 'WordPress/gutenberg' }} | |
| if: ${{ github.repository == 'WordPress/gutenberg' || github.event_name == 'pull_request' }} |
Not a blocker: Should we also run this CI on PRs submitted to forked repos? Some other CIs seem to do that. I think it's ok to go either way.
There was a problem hiding this comment.
Good catch, I think I removed this part unintentionally 🙈
Co-authored-by: Aki Hamano <[email protected]>
westonruter
added a commit
that referenced
this pull request
Jan 7, 2025
…ry/interactivity-lazy-hydration * 'trunk' of https://github.com/WordPress/gutenberg: (143 commits) Update: Bundle upload media. (#68522) Add: Media field changing ui to Dataviews and content preview field to posts and pages (#67278) Bump the react-native group with 2 updates (#68095) Check Storybook build on CI for PRs (#68466) Bump the github-actions group across 1 directory with 2 updates (#68436) Classic theme preview: remove admin-bar class name (#68519) Remove geriux as code owner (#68523) Post Featured Image: Adds control to clear the the overlay color (#68525) Components: Standardize reduced motion handling using media queries (#68421) Upgrade Playwright to v1.49 (#68504) Document Outline: Use block client ID as unique 'key' (#68502) Storybook: Add UnitControl story (#67346) Details: Add allowedBlocks and TemplateLock attributes (#68489) Post Comment Link: Show Border Control By Default (#68506) Query Total: Show Border Controls By Default (#68507) RSS: Added Colour support (#66419) Refactor: Separate input form styles to a dedicated stylesheet (#68501) Code quality: Fix typos (#67304) Page List: Added color support (#66430) Fix flaky DataViews list arraow nav e2e tests (#68503) ...
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)