Review usage of Semantic Releases

[alukach]

Is the system of Semantic Releases more trouble than its worth? I am a bit of an optimist on the strategy, but others have described it as opaque and too much magic. Should we remove it from our build system?

Pros:

• Automation means releases are near-instant.
• Busywork (e.g. upping the package version, writing release notes) are automated

Cons:

• Requires a commitment to Conventional Commits
• More challenge around understanding what the impact of commit will be (ie what will the be the resultant version change?)
• Many small (single-change) releases (I'm admittedly not sure if this is actually a bad thing)

My urge to is to lean more into the strategy and build in more CI tooling that would:

• reject PRs that don't comply with conventional commit standards (although, I think #25 recently added this)
• comment on a PR informing the user of what the next version will be if the PR is merged.

Thoughts @sharkinsspatial @emileten ?

[emileten]

@alukach thanks !

More challenge around understanding what the impact of commit will be (ie what will the be the resultant version change?) Many small (single-change) releases (I'm admittedly not sure if this is actually a bad thing)

These are the two concerns for me. I think the former could be mitigated by having a nicer documentation regarding where releases happen (#32) and how those happen -- Perhaps in the README something a bit more detailed like :

Versioning is automated in this repository :

• First, Pull Requests titles must comply with the format of Conventional Commits, that define a set of categories that a given PR can fall in.
• Second, when a Pull Request is merged, it is automatically analyzed by a Semantic Release bot which follows the Conventional Commits format to determine whether or not a new release should happen, and if so, what the new version should be.

Regarding the latter concern, I don't know what the best practice is.

[emileten]

Just adding another comment that would be in the side of 'Cons' here.

I have been working on adding 'integration tests', which is just a github action that builds eoapi-cdk and runs an example real world deployment to check everything works before doing a release. It was intended to be an automated workflow, but I ended up defining it as a manual github workflow because I struggled a lot to integrate it to our automated release system.

More details here, but the gist is : this workflow is costly, because it's a real deployment. We only want to do it if we are going to do a release, but it's semantic-release that decides if we do one or not, and I failed finding a reliable way to code up something like "if semantic-release is about to make a release, run the test deployment".

I resorted to a manual deployment workflow + a reminder in the PR template because of this.