This site is configured to build its doc pages from a variable version of the content in the Storybook monorepo. This is mostly automated.
In this document, assume "latest" is
6.3
and "next" is6.4
."monorepo release branch" =
main
,next
, andrelease-x-x
(starting withrelease-6-0
)."frontpage release branch" =
main
andrelease-x-x
(starting withrelease-6-0
).
When a pre-release ("next") version (6.4
, in this document) graduates to stable, and therefore a new "next" version (6.5
, in this document) is cut:
First, in the monorepo:
Important: After each of these steps, cancel any Netlify deploys that are kicked off.
This is to avoid publishing any confusing states in the version selector.
- Create a release branch from
main
release-6-3
, in this document
- Delete the previous "next" release branch
release-6-4
, in this document- This is done to maintain proper hygiene, as it would otherwise be the only
release-x-x
branch that doesn't serve a purpose
- Follow the normal monorepo release process for
main
andnext
branches - Make sure all release branches, including
main
andnext
, have an appropriate version in their rootpackage.json
Second, in this repo:
- Make sure each release branch in the monorepo has a corresponding release note, and that their contents are correct
- But do not push these changes yet
- In the Netlify branch deploy setting:
- Add the version that was "latest"
release-6-3
, in this document
- If present, remove the version that was "next" from the Netlify branch deploy setting
release-6-4
, in this document
- If you would like to publish pre-release docs
- Add the version that will be "next" to the Netlify branch deploy setting
release-6-5
, in this document
- Add the version that will be "next" to the Netlify branch deploy setting
- Add the version that was "latest"
- Push any updates to
main
- i.e. merge the PR containing the changes from Step 1
- This kicks off a production deploy and a workflow to deploy all release branches
🚨 IMPORTANT — Make sure all of the Netlify builds are successful, especially production.
If you make monorepo changes that require rebuilding all release branch deploys
e.g. updating "next" from
6.4.0-beta.30
->6.4.0-rc.0
would change the version label rendered in the VersionSelector, which is available on all deploysYou can kick off the
push-all-release-branches
workflow manually (againstmain
). (More info)
- Pushing to a monorepo release branch triggers a workflow:
- On push to
main
- Use webhook to kick off production frontpage deploy
- On push to
next
- Creates & force-pushes
release-6-4
branch - Sends dispatch event to this repo which kicks off a workflow to create and force-push
release-6-4
branch
- Creates & force-pushes
- On push to
release-x-x
- If pushing to
release-6-4
- Warns that changes will be lost on next push to
next
- Warns that changes will be lost on next push to
- Else
- Sends dispatch event to this repo which kicks off a workflow to create and force-push
release-x-x
branch
- Sends dispatch event to this repo which kicks off a workflow to create and force-push
- If pushing to
- On push to
- Pushing those
release-x-x
branches in this repo will kick off a Netlify branch deploy for the appropriate version. - When the docs content is extracted from the monorepo, each of the other version's info is extracted as well (for generating the list of available versions)
- Based on the latest and current version info, the site adjusts the URLs and other details appropriately. (See the PR for details.)
- Using Netlify proxy rewrites, the production site and branch deploys are stitched together to appear as a single site.
Pushing to main
in this repo kicks off a workflow which will create new release branches from main
and push them, kicking off branch deploys for each.
- This ensures all branch deploys stay in-sync with any updates to production
- If you're pushing a change to
main
that does not need to make corresponding changes to the release branch deploys, you can skip the workflow.