Closed fadeenk closed 5 years ago
Ok, so, I resolved a few issues with this but not all of them.
https://github.com/mikeal/merge-release/commit/219bc5f01be994f1873e5a21b3487b0419663365/checks
The first issue, and I should have remembered this since I already had to write it for https://github.com/mikeal/publish-to-github-action , was that the local checkout isn’t setup for pushing.
The next problem we have is that the default checkout isn’t on a branch but in a detached HEAD. I’m working on a fix now.
Sounds good. I looked at the changes and they look good. However I would rather do a new commit for the version bump instead of amending the previous one maybe something like git commit -a -m "[Release] ${newVersion}"
instead of git commit -a --amend --no-edit
that way you dont have to overwrite history by changing the last commit.
Let me know if there is anything I can help with
update: wow! that was much harder than I thought ;)
at some point a release of merge-release
was published of a commit that failed to push. this exposed another awful bug that took hours to find where we failed very badly when the published commit can’t be compared in the git history to the current commit. that’s fixed now.
i moved a lot of things around and played with a few different ways of managing the merge and the commit data. i had it working long enough to decide to back out the commit step. it seemed like a nice idea to check the package.json in after each release but it’s actually quite annoying because after every push you need to do a new pull into your dev environment 5-10 minutes after because the remote was just updated. it’s also just totally unnecessary, because we have the tags now so we don’t need any other reference to find a particular release in the history.
anyway, this feature (automatic tag pushing) is in now, with no change to the commit history.
I added some docs and put the BREAKING notice in the log, so the next version published should see a major version bump.