Setup v4 releases #15961
Merged
Setup v4 releases #15961
Conversation
This file contains hidden or 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
Trigger on pushes to the `next` branch, instead of relying on a manual workflow dispatch.
If a version is passed, all packages will be set to that version.
This was already done during the prepare release step
This was already done during the prepare release step.
This will compute the release channel we are interested in. Typically, this will be just `latest`, but could also be `beta` in case of `5.0.0-beta.2`
Or manual workflow_dispatch trigger.
This should not be necessary anymore, the NPM tag will be published based on the version in `package.json` of the `tailwindcss` package.
We will mostly always publish to `latest`, so this step is unnecessary.
RobinMalfait
commented
Jan 28, 2025
|
|
||
| const __dirname = path.dirname(url.fileURLToPath(import.meta.url)) | ||
| const root = path.resolve(__dirname, '..') | ||
| const version = process.argv[2] || null |
There was a problem hiding this comment.
This just allows us to force a version without manually editing the versions. E.g.:
pnpm run version-packages 0.0.0-insiders.abc123
There was a problem hiding this comment.
I couldn't immediately find an option in pnpm to do that recursively, so thought to just add it to this little script 😄
For testing purposes only
This reverts commit 572dddf.
philipp-spiess
approved these changes
Jan 28, 2025
| script: | | ||
| await github.rest.actions.createWorkflowDispatch({ | ||
| owner: 'tailwindlabs', | ||
| repo: 'play.tailwindcss.com', |
There was a problem hiding this comment.
We probably need to update play so that it uses v4 config for the insider build after that release cc @thecrypticace
There was a problem hiding this comment.
Yep, @thecrypticace is aware of this 💪
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.
Now that Tailwind CSS v4 is released, we can setup a proper release workflow again. This setup mimics the workflow of how we did it in v3, but adjusted to make it work on the v4 codebase.
Whenever a PR is merged into the
nextbranch, we will publish an insiders release to npm using the following version number:0.0.0-insiders.<commit-hash>. Note: insiders releases will not have a GitHub release associated with them, therefore thestandalone-cliwon't be available as an insiders release.For the normal release procedure, the following steps are required:
pnpm run version-packages)Next, a GitHub action will kick in once a
tagis being pushed.The GitHub action will run a build, and create a draft release on GitHub that will contain:
standalone-cliartifacts attached to the drafted releaseOnce you are happy with the draft, you can publish the draft on GitHub.
This in turn will trigger another GitHub action that will publish the packages to npm.
Whenever an insiders release or a normal release completes, we will also trigger Tailwind Play, to update its dependencies to the latest version of Tailwind CSS.
Note: some of the GitHub Action workflows still refer to the
nextbranch instead of themainbranch. If we later today want to get a new release out, we can mergenextintomainand update the workflows accordingly.This is hard to test, but I started from the existing release.yml file and adjusted things accordingly. The biggest change is related to the insiders version. If you look at this temporary commit, you can see that the publishing (dry-run) seems to work as expected:
