Fork-ts-checker-webpack-plugin: Discussion: releasing

[phryneas]

CC @piotr-oles @johnnyreilly

So as I noticed in #283, our current way of rebasing beta into master won't work. Github rewrites hashes even if there is no need to and this means, with every release, master and beta will be out of sync history-wise even if they contain commits with the same message etc.

Especially for future PRs, this is super-confusing.

So my idea: why don't we trigger this from the CI?

To release, we could use a custom build trigger from travis - we'd trigger a build from there, setting RELEASE=true and then in the build job, we could have a conditional stage release.

That stage would essentially be a script like this:

git fetch origin
AHEAD=$(git rev-list --left-right --count origin/master...origin/beta | cut -f1)
[ "$AHEAD" = "0" ] || { echo "master is ahead of beta, skipping."; exit 1; }
git checkout master
git reset --hard origin/beta
git push -f origin master

Note that this is not my favourite way of doing this, just a practical one. I'd very much prefer a UI that is made for this specific task - maybe you could share this tweet (or just ask around yourselves :) ) and maybe someone knows of a UI exactly for that purpose

[johnnyreilly]

Are you saying that semantic release will never work without manual intervention?

I'm surprised if that's the case as that would kind of defeat the purpose of it to a certain extent. I mean to say: semantic release is supposed to remove friction from the release process. If I understand you correctly, given the way GitHub works, there is always going to be this added friction; literally having to manually update commits for each release. Do I understand you correctly?

I think it's super cool that you've come up with a solution. That's amazing! Well done!

But where this leaves me is here: are we using semantic release correctly? Surely it can't be the case that everyone is doing this? Can they? Why would they be willing to put up with the inconvenience?

Is our setup in some way custom? If so, can we adjust it so we're going with the default flow instead? I'm very much in favour of not deviating too much when you're using someone else's service / tool. Whenever I've done that I've just made future me angry and sad with past me. 😁

If things are as described then I don't see us getting value out of semantic release. And I'd dearly love for us to crack this!

@piotr-oles what are your thoughts? Can we make this work? If we can't I think it's worth considering whether we revert back to using Travis to handle this again. That worked without confusion. It wasn't fancy but it was simple and reliable. That's a good thing in a release process 😁

[phryneas]

I guess that usually, people don't do the releases out of the github GUI, but they do it from the command line by doing something like

git fetch origin
git checkout master
git merge --ff-only beta && git push master

(on a side note: this is much more simple than what I wrote above and should absoutely do the trick - I was not aware of --ff-only.)

The thing we tried - doing a PR from beta to master to do a release - will never work with the current github PR UI.

So, either we just release from cli, or we need some option in a CI/with a bot that does it for us.

[johnnyreilly]

What about if we got rid of the beta step - PRs off master again? Merging a PR to master triggers a release. Would that work?

[phryneas]

Yeah, but we would lose @next - and I think that's quite valuable. I think it's nice that we can dogfood bigger changes for a few days and then decide to release them after a while.

PS: also, I had that idea of running only a subset of the tests on PR and the full suite with extra node versions etc. on a daily basis against beta.

PPS: I also asked here: https://spectrum.chat/semantic-release/general/how-do-you-trigger-your-dev-master-merge~9cfb7a38-1b79-4718-9208-3c527a0e7822

[piotr-oles]

https://github.com/semantic-release/semantic-release/blob/beta/docs/recipes/pre-releases.md here we have a workflow proposed by the semantic-release

[johnnyreilly]

So are they manually having to fix up every PR to get the release working? That seems so unlikely.... Do we just have the recipe slightly wrong?

Have we forgotten to add salt? 😉

By the way, this issue looks problematic: https://github.com/Realytics/fork-ts-checker-webpack-plugin/issues/286

Maybe all semantic releases are triggered by command line...

Random other thought: can we use GitHub actions to help us out of our hole? We use them on ts-loader: https://github.com/TypeStrong/ts-loader/blob/master/.github/main.workflow

In this case to have a release workflow very much like the one fork-ts-checker-webpack-plugin used to use. But you can use GitHub actions to do anything 😄

I've blogged about them a bit: https://blog.johnnyreilly.com/2019/01/github-actions-and-yarn.html

[phryneas]

https://github.com/semantic-release/semantic-release/blob/beta/docs/recipes/pre-releases.md here we have a workflow proposed by the semantic-release

Phew. that kind of looks like Merge-Commit hell :(
I mean, I understand that when you have multiple branches and sneak in fixes into master that don't go through beta before, you have to do that.

But still... not really appealing to have one merge-commit for every stage advancement :neutral_face:

[phryneas]

@johnnyreilly If we can manually trigger a github action, then we could use it to do that merge. And from there on, semanic-release could take over in travis - that would be quite elegant as we'd never have to leave github for it.

The only question is what event to trigger on.

Maybe commit_comment - so you could just comment "release this to master" on a commit and then the action merges that into master? (if the comment was on the beta branch and the commit commented on was ahead of master.)

Or can repository_dispatch somehow be triggered from the github UI?

Or can you just trigger an action manually? I haven't used these yet :grin:

[johnnyreilly]

Or can you just trigger an action manually? I haven't used these yet 😁

I may have jumped the gun here; GitHub actions are still in beta and there's actually very few events you can hook into as yet... (And I don't think you can trigger them manually - it's all about the events)

I've been thinking about this overnight (slept badly to be honest 😁)

Here's where I am right now:

1. we have a release process that I doesn't work without manual intervention

2. I don't understand what that manual intervention is. So I wanted to do a release today I'd need the assistance of someone that did.

If we want to keep using semantic release I think we need to solve 1. I'm totally up for us continuing to use it but I feel that it has to be straightforward. Semantic release should help us, not hinder us. I'll say that at the moment it hinders us. That makes me 😭

On 2, would @piotr-oles / @phryneas be able to advise on what the steps are presently to successfully release using semantic release? We should also update https://github.com/Realytics/fork-ts-checker-webpack-plugin/blob/master/CONTRIBUTING.md with that information. Anyone who follows these steps presently will be sorely disappointed 😁

I'd 💖 for us to get to a place where releasing is completely boring. It just works. Hopefully we can!

Heads up: I'm away camping from today ⛺🎪🏕️ and so likely won't be online much until Sunday night. So if you don't hear much from me it's probably because I'm somewhere under canvas remembering why I generally prefer living in a 🏠 😉

[piotr-oles]

I think I've got a wrong approach to the beta branch - it shouldn't be protected. It's more like a temporary branch to work on the experimental features.

My plan is to:

• [x] remove protection rule on the beta branch
• [x] update CONTRIBUTING.md file

The workflow would be:

1. create a beta branch if we want to work on the feature that is complex
2. merge when work will be done
3. remove beta branch

That would make more sense - we would be able to add fixes to the stable release and work on the beta release in the parallel.
What do you think about that approach? It's basically the approach from semantic-release documentation.

[johnnyreilly]

Sounds great! Go for it! 🥰

[phryneas]

I guess that would work :)

[piotr-oles]

I think we are ready to use the new flow - as contributors you have full control over beta branch - you can update it with --force flag in case of rebasing, you can remove it and create again.

[johnnyreilly]

I'd like to test out the new flow. At the moment I'm not confident I can get a release out. I very much want to get back to the point where I feel I can make a release happen 😁

So I'm planning to raise a docs only PR against master, merge it and hopefully see a release flow out automatically. Codewise it'll be identical to what we have now but it will ensure we're simply releasable again.

Is there anything I need to know before I do this?

[piotr-oles]

I'm not sure if doc change will create a new release. As far as I know, we need a fix, feat or BREAKING CHANGE.

[johnnyreilly]

Okay maybe I'll do a fix: test the new release process. The new release should be identical codewise to the last one. (This is just checking we're in a state where releasing is simple.)

[johnnyreilly]

Just attempting the new workflow now. Unfortunately it looks like prettier isn't playing nice on Windows. I did a change to the README.md and it errored out with this when I tried to commit:

× prettier --write found some errors. Please fix them and try committing again.


[error] README.md: TypeError: Cannot read property 'Symbol(Symbol.iterator)' of object
[error]     at _iterableToArrayLimit (C:\source\fork-ts-checker-webpack-plugin
ode_modules\prettier\bin-prettier.js:2137:22)

I ended up doing the formatting in VS Code using the prettier extension and then committing.

[piotr-oles]

I think that the release process is stable now and we can close this discussion :) We can re-open it if there will be any issues in the future :)