Add semantic release integration

[piotr-oles]

Automates releases, versioning and changelog generation ✨

Release branches are:

• beta - for pre-releases
• master - for releases
  Merging to these branches starts release process.

[johnnyreilly]

Wow this is big and exciting! I don't think I fully understand all of this so maybe I'll ask some questions and you can advise?

This PR deletes the CHANGELOG.md. For me that's a concern as there's a lot of useful information in the changelog. I refer to it quite often. And certainly when I did the 1.0.0 release, I put a lot of info in there: https://github.com/Realytics/fork-ts-checker-webpack-plugin/blob/master/CHANGELOG.md#v100

For me the changelog is a feature. I ❤️ it 😉

How do we keep that information available in semantic release world? Is it only visible on the releases page in GitHub? How does that work in the case of wanting to write some detailed notes as in the case of the 1.0.0 release? Your PR mentions CHANGELOG.md generation, so what would the generated one look like? And can it be verbose when needs be. Mostly we don't need that. But occasionally...

Next question: what's the actual release process? There's a lot of changes in the PR and I didn't notice where that is explained? No doubt it's there; but I missed it 😊

[piotr-oles]

Currently we have CHANGELOG.md and GitHub Releases - we duplicate information about releases. I've just added info to the CHANGELOG.md that information about releases is available on the GitHub.

The deploy process is described well on the semantic-release page (I have installed beta version of the semantic-release to handle pre-releases).
In our case:

• contributors follows conventional-commit standard (enforced by a git-hook/husky)
• merge to the beta branch creates release - semantic-release lists commits that have been added before last release and based on that:
  • computes version - for beta branch it will be pre-release version, for example: 1.0.5-beta.0
  • creates GitHub release with list of changes and BREAKING CHANGES
  • creates npm release - for the beta branch it will be released on the beta channel`
  • then if beta version works well for other users, we create pull request to the master - then release will be created as well (not pre-release like on beta branch)

To sum up - we will have to mind about proper commit message - this will be the input for the next version bump and the changelog :)

[johnnyreilly]

Currently we have CHANGELOG.md and GitHub Releases - we duplicate information about releases.

We do. I do find it useful having that info in source code rather than just in GitHub releases. Admittedly it's unlikely we'd ever move away from GitHub, but if we did we'd have to work out a way to transfer that information manually.

I'm doing a fair amount of k8s at the minute which has left me with the instinct "everything should be in source control". This departs from that.

Also occasionally it's kinda handy (particularly if you're offline) to be able to refer back to the changelog without needing an internet connection.

The deploy process is described well on the semantic-release page (I have installed beta version of the semantic-release to handle pre-releases).

Thanks - I'll have a read.

It sounds like everything ends up being generated from commits. Maybe that's fine....I haven't tried it. But different can be good 😊

What's the story with squash and merge? I ask as many PRs are a collaborative process. Take: https://github.com/Realytics/fork-ts-checker-webpack-plugin/pull/231/commits

It already has a bunch of commits on there and is likely to gain lots more. I'm kinda fine with that as people can try things out, commit with gay abandon, and when we're done we just squash and merge into a single clean commit with a meaningful comment.

My concern here is that we may end up not being able to use squash and merge and instead have to take say 20 commits which represent a work in progress. It may only really be an individual commit we're interested in. We don't want the comments for commits along the way that didn't end up being an approach we end up using.

What happens in this case?

None of this is me saying "no" BTW - but I'm keen we have a workflow that supports us well and so I want to talk through the tricky scenarios. 😁

[piotr-oles]

I get your point - I will add semantic-release/changelog plugin to generate CHANGELOG.md file as well :)

In terms of merging Pull requests - if there is more than 3 commits, I would prefer to squash them. When we squash we are able to change a commit message - this is where we can describe changes that will affect version bump and changelog :)

Let's say that we have Pull request that adds node Worker Threads support and requires node >= 11 but unfortunatenly it contains 100 commits. We can squash these commits and type commit message as:

feat: use `Worker Threads` instead of `process`

In order to gain performance boost, we switched from node `process` to `Worker Threads`. This will reduce memory consumption and startup time.

BREAKING CHANGE: minimal node version changed from 6 to 11 - `Worker Threads` required the node >= 11

[piotr-oles]

Updated - it should generate CHANGELOG.md file as well :)

[johnnyreilly]

Could you catch this up to master please? Then I assume we're ready to merge?

And every time we merge to master a release will magically be cut and released?

Perhaps you'd like to do the honours and merge this, and watch a release magically appear on npm? 😎

[piotr-oles]

Done :)

[piotr-oles]

This will be merged to the beta branch, so master will not be using semantic release. We will have to merge beta to the master to start semantic release flow there.

[johnnyreilly]

This will be merged to the beta branch, so master will not be using semantic release. We will have to merge beta to the master to start semantic release flow there.

Will we need to do this every time?

I can see you've raised this PR against beta. I'm guessing most people will raise it against master. For them releases will go straight out presumably?

And if someone wants something to go out as a beta in future then the way they do that is by raising a PR against beta. Is that about the size of it?

Also, I've just realised I've put commits on this PR that weren't made using the new mechanism... Is that going to be an issue? Or can you squash and merge your way to glory? 😄

[phryneas]

Essentially, as I understand it, everything in beta gets directly published to npm as @beta and when you want to do a proper release, you PR beta against master which cuts the real release.

So yes, all PRs should first get merged into beta. That's not too bad - switching a PR from master to beta after initially doing it against master is super-painless - I just did it over in #253.

[johnnyreilly]

Essentially, as I understand it, everything in beta gets directly published to npm as @beta and when you want to do a proper release, you PR beta against master which cuts the real release.

This is going to need some getting used to! I'm game though 😄

[piotr-oles]

@johnnyreilly Commits that are not following conventional commit schema are just ignored. As far as I know, there is no way to force a commit schema in the GitHub web app. I will squash them anyway 😃

There is a lot of people using this plugin - we should be more careful about releasing new version on the stable channel 📦 That's why I propose to use beta channel for new features.

@phryneas Exactly -

• first merge to the beta branch -> release on the @beta channel on the npm
• then merge beta branch to the master branch -> release on the stable channel on the npm.
  From this point we should not merge directly to the master ⛔️

[phryneas]

@piotr-oles something still seems to be wrong there: Skipping a deployment with the script provider because this branch is not permitted: beta

https://travis-ci.org/Realytics/fork-ts-checker-webpack-plugin/jobs/522570604

[johnnyreilly]

It's weird - I can see that the merge has taken place though: https://github.com/Realytics/fork-ts-checker-webpack-plugin/tree/beta

Although there's no update to the CHANGELOG.md on beta...

@piotr-oles can you advise please?

[piotr-oles]

I’will take a look tomorrow :)

[piotr-oles]

🎉 This PR is included in version 1.2.0-beta.1 🎉

The release is available on:

• npm package (@beta dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[johnnyreilly]

@piotr-oles I'm assuming this means you managed to remedy the problems?

I've just shipped #260 (comment) v1.1.1 using the old approach.... Are we now ready to try the new approach?

[piotr-oles]

There is still a problem with updating CHANGELOG.md - I have to debug this. I hope to fix it today :)

[piotr-oles]

🎉 This PR is included in version 1.2.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀