Enable pre-release workflow

[cristiano-belloni]

Workflow proposal

1. Every time we want to make a pre-release, we create a release/... long-lived branch
2. In the release branch, we enter pre mode. Normally we want to set the npm tag to be next (yarn changeset pre enter next), but if we want to have concurrent tags, we can have them (yarn changeset pre enter other_tag)
3. We branch off the release branch and create PRs to it as it was main, updating our changesets normally
4. Like with main, every time we push to the release branch, a changeset-release branch is created (for example, release/webpack-5 will generate changeset-release/release/webpack-5). If that changeset-release branch is merged back into the release branch, a prerelease version should be published to the npm tag we chose at point 2 (normally next)
5. When the release branch is finished and ready to go into main, we exit pre mode (yarn changeset pre exit) and we create a PR from the release branch into main. If we forget to exit pre mode, the CI will catch it and not let us merge back into main

Summary of the upcoming webpack 5 pre-release after discussing it, for reference (thanks @steveukx):

• As described in this PR we will have a release/webpack-5 to contain the upgrade from webpack 4 -> 5
• Publish the changes to @alpha-webpack5 tag on npm
• Once testing is complete, would mean merging back into main and an @alpha-webpack5 tag pushed to npm
• Any change in main will need to be merged into @alpha-webpack5 (process to be owned by the developer)
• On completing testing, deprecate or delete the tagged version

Changes in this PR

Preparatory work for the changeset pre-release flow

• Allow release/* branches to trigger the release workflow
• Allow release/* branches to trigger tests
• Allow release/* branches to trigger static analysis
• Allow release/* branches to trigger validate
• Fail checks if any PR to main (or commit to main itself) is in pre-release mode
• Upgrade action changeset to @v1 (master is deprecated)

[changeset-bot]

⚠️ No Changeset found

Latest commit: 6a34ec9

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[coveralls]

Coverage increased (+0.5%) to 28.689% when pulling 6a34ec9 on feature/check-pre-release into 6c8dc62 on main.

[LukeSheard]

I'm not sure this will have the desired behaviour, since running the pre-release check on any CI including release will also fail.

I would suggest that if we want to setup a pre-release branch we setup CI so that a dedicated branch creates a prerelease PR on that base branch if we merge into there. Then we can enable / disable this workflow depending on whether we want to use it or not.

[cristiano-belloni]

since running the pre-release check on any CI including release will also fail.

Yeah, that's true. I can duplicate the workflow for main and release branches though, I'd like to avoid having a dedicated branch and turning on and off stuff because it's easy to get it wrong.

[cristiano-belloni]

@LukeSheard I created a standalone workflow to check pre mode, it's a lightweight (3 secs) concurrent check. I also added the desired workflow in the description, if it makes sense, so we can comment on it.

[cristiano-belloni]

Good conversation with @LukeSheard about our options:

1. Merge this branch and use changesets pre to publish to @next (see workflow in description).
   • pros
     1. we don't block main, can advance latest independently and use changeset normally
     2. might be the easiest / quickest thing to do in the interim
   • cons
     1. complex to handle - merge back into next is something that we have to do consciously & carefully
     2. not trunk-based, many distributed branches
2. Provide our cutting edge features in main / @latest, under a feature flag
   • pros
     1. we don't need a complex release workflow
     2. trunk based
   • cons
     1. more code to maintain, more tests, more things that can fail, more combinations of flags for the user to remember
     2. might need to use npm aliases (for example, webpack5 upgrade)
3. Split the build / start scripts in many packages - one for esbuild, one for webpack4, one for webpack5
   • pros
     1. all the pros of "Provide our cutting edge features in main / @latest, under a feature flag"
     2. code is better organised
   • cons
     1. massive refactoring needed which might need a lot of time and a pre-release itself :)

[benpryke]

Should we also run the validate workflow on release/** branches?

[cristiano-belloni]

Should we also run the validate workflow on release/** branches?

Good catch, done.

[LukeSheard]

In line with this I've also disabled direct pushes to release/** branches so this makes sense.

Would it not also make sense to create a check which merges upstream changes from main into release/** branches? Or at least creates a PR for it?

[cristiano-belloni]

In line with this I've also disabled direct pushes to release/** branches so this makes sense.

Thanks!

Would it not also make sense to create a check which merges upstream changes from main into release/** branches? Or at least creates a PR for it?

I don't think we want it automatic right now because when we merge upstream we want to regenerate the pre.json too, and I'd like to handle that manually, at least for the first times.