chore: update preview release workflow to use snapshots #5365
Conversation
|
Branch previewReview the following VRT differencesWhen a visual regression test fails (or has previously failed while working on this branch), its results can be found in the following URLs:
If the changes are expected, update the |
Tachometer resultsCurrently, no packages are changed by this PR... |
There was a problem hiding this comment.
I have made some changes to the beta release process so that we can leverage the current functionality and the version number will also look like this 1.5.0-beta.0 1.5.0-beta.1, 1.5.0-beta.2, and so on..
#5366
castastrophe
force-pushed
the
ruben/beta-snapshot-releases
branch
from
475ec04 to
e5ef447
Compare
| @@ -11,7 +11,7 @@ jobs: | |||
| name: Build & publish site | |||
| runs-on: ubuntu-latest | |||
| # Run the job if manually triggered or if the commit message includes '#publish' & the check suite has passed or if the commit message includes 'docs' and the check suite has passed | |||
| if: github.event_name == 'workflow_dispatch' || contains(github.event.head_commit.message, '#publish') || contains(github.event.head_commit.message, 'docs') | |||
| if: github.event_name == 'workflow_dispatch' || contains(github.event.head_commit.message, '#publish') || contains(github.event.head_commit.message, 'docs:') || contains(github.event.head_commit.message, 'docs(') | |||
There was a problem hiding this comment.
more explicit to avoid a commit message that has the word docs in the message. this ensures it is of the commit type docs
caseyisonit
changed the title
Description
This PR updates the beta release workflow to use the snapshot approach for generating unique versions.
We had previously planned to have incremental suffixes for the beta releases (e.g.:
1.5.0-beta.0,1.5.0-beta.1, etc.). But this was not working because in CI we do not persist the latest published version, so we would always try to publishbeta.0. In this PR, we now use a snapshot approach that adds unique timestamps instead (e.g.1.5.0-beta.20250411081626) ensuring there are no conflicts! :)Motivation and context
The beta release workflow was previously not working correctly after the initial run due to version conflicts (you can see an example run).
The CI environment does not maintain state between runs (it does not know which beta version was last published), so it would always try to publish the same beta version (e.g.,
1.5.0-beta.0):The workflow now uses
yarn changeset version --snapshot betawhich together with a new changeset config, uses the calculated version and format the version to our desired version output. And by appending a unique timestamp-based suffix, we ensure each CI build creates a distinct version number that won't create conflicts.How has this been tested?
yarn changeset version --snapshot betapackage.jsonof any of the components (e.g."version": "1.5.0-beta.20250411081626")Types of changes
Checklist
Best practices
This repository uses conventional commit syntax for each commit message; note that the GitHub UI does not use this by default so be cautious when accepting suggested changes. Avoid the "Update branch" button on the pull request and opt instead for rebasing your branch against
main.