Automated Releases with semantic-release fails to push

[oscard0m]

Apparently automated releases with semantic-release are not working right now for this project. I'm opening this discussion to collect enough info to create the corresponding spikes or GitHub issues to address the problem.

@kettanaito could you please share an example or more insights on this when you have time?

Thanks

---

Originally posted here:

One particularly problematic area I'm dealing with right now is automated cron releases with semantic-release. I'm having trouble with semantic-release to create a version commit and push it to Git. Although I'm signing that commit as myself (admin), it still fails to push with the "require 2 checks to pass" (branch protection rules) errors.

[kettanaito]

Hey, @oscard0m. Thanks for opening this.

Currently, there are multiple problems with the automated release:

1. The release job makes the tests flaky. This sounds silly but whenever the tests are run from the prepublishOnly hook they seem to often fail randomly. Those are not flaky tests on their own, as they pass reliably in the ci workflow every time, not to mention they also pass locally. I've moved tests from that hook and now run them as preceding steps of the release workflow, which seemed to have fixed the issue but I think, occasionally, I still see things fail for no apparent reason.
2. The version commit made via @semantic-release/git cannot be pushed, it gets denied by GitHub. I'm using my (admin's) email address and login for that commit, which should allow it to be pushed regardless of the protected branch checked (I don't have "Include administrators" checked in the repository settings). And this does work on another repo where I have a similar setup but it fails with MSW.

remote: error: GH006: Protected branch update failed for refs/heads/main.        
remote: error: 2 of 2 required status checks are expected. Changes must be made through a pull request.        

• Failed job

We need to commit the version bumps to package.json for discoverability. I don't think that marking "version": "0.0.0.-semantically-released" is generally a good idea.

I've also noticed that the integration tests seem to be failing right now due to type errors. This may be a regression of #1073.

[kettanaito]

Regarding the failing integration tests, seems to be a silly issue on my part:

bdaa8d3

Fixed. Now the tests should fail in the ci job as well as there are some type violations.

[kettanaito]

I think it's worth writing down my expectations from the automated releases so we know where to move.

Scheduled

Releases must be scheduled so there's as little human involvement as possible. I currently have them as a cron job that runs at 11 PM every day. We may extend this window eventually but I find it sufficient for now.

Why: So that each merge doesn't trigger a new release. I want to be able to merge different things throughout the day and have them all released under a single version.

Conventional

Releases must use Conventional Commits to determine next versions of the package. That's something semantic-release does well and I have no other feedback regarding this point.

Committed to Git (and GitHub)

Releases must be committed to Git. This includes the release version bump in package.json and the respective Git tag. This also includes creating a new Release on GitHub (which semantic-release does well).

[oscard0m]

Hey @kettanaito !

I've been catching up with lots of GitHub notifications and pending work. I hope you are doing fine. Congratulations on your GitHub Sponsorship btw 👏🏽 !

Before getting deeper into the actual issues you reported here, I think is important we are on the same page on your previous message first.

I think it's worth writing down my expectations from the automated releases so we know where to move.

Scheduled

Releases must be scheduled so there's as little human involvement as possible. I currently have them as a cron job that runs at 11 PM every day. We may extend this window eventually but I find it sufficient for now.

✅ I agree the least human involvement is involved the better, especially if there are several merges to the main branch on the same day.

Why: So that each merge doesn't trigger a new release. I want to be able to merge different things throughout the day and have them all released under a single version.

• Why you don't want to trigger a new release on every merge?

  • Isn't each commit self-contained enough to be worth a release?

• I think we can think about your concrete use case and adjust semantic-release to your needs.

  • Maybe working with prereleases?
  • If you want we can have a chat about this, in Octokit they have everything automated and for sure they can help us with your use case.

Conventional

Releases must use Conventional Commits to determine next versions of the package. That's something semantic-release does well and I have no other feedback regarding this point.

✅ Awesome! I'm happy with Conventional Commits as well.

Committed to Git (and GitHub)

Releases must be committed to Git. This includes the release version bump in package.json and the respective Git tag. This also includes creating a new Release on GitHub (which semantic-release does well).

✅ Yep! semantic-release manages this automagically as well 🕺🏽 💃🏽

---

Let me know what are your thoughts. If you want to have a chat/call ping me here or Twitter :)

[kettanaito]

Hey, @oscard0m. Thanks for reaching out!

I've migrated to a custom-built solution since this discussion has been started. I judged it to demand less involvement than having to configure semantic-release in each repo. Unfortunately, the behavior I want from the release automation tooling is not the default behavior that SR provides. Even once I've used plugins and such, it was still flaky and at times strange. I've decided to write my own thing to use for my open source, and it worked wonderfully thus far. In fact, the last couple of releases across the MSW ecosystem were done with that custom tool.

I'm happy with the state of release management right now, so we can consider this discussion obsolete 🎉

[oscard0m]

Hey, @oscard0m. Thanks for reaching out!

I've migrated to a custom-built solution since this discussion has been started. I judged it to demand less involvement than having to configure semantic-release in each repo. Unfortunately, the behavior I want from the release automation tooling is not the default behavior that SR provides. Even once I've used plugins and such, it was still flaky and at times strange. I've decided to write my own thing to use for my open source, and it worked wonderfully thus far. In fact, the last couple of releases across the MSW ecosystem were done with that custom tool.

I'm happy with the state of release management right now, so we can consider this discussion obsolete 🎉

Amazing news @kettanaito! I'm glad to read you have a custom solution working and you are happy with the state of release management right now.