Automate Release Process

[skorfmann]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

We should have an automated process to create PRs for a new release. Let's use https://github.com/semantic-release/semantic-release or something similar and use conventional titles for PRs which can be enforced with an GH Action like this

The workflow I'm imagining:

• Regularly merged PRs to main will trigger a pre-release (see Package Pre Release Versioning #561 as well) - no changes required as part of this issue
• A manually created release PR contains all the required changes generated by the semantic release tooling (version and changelog)
• The actual package release pipeline should stay as it is

For the PR validation, a config like this should work (inspired by this):

scopes:
  - lib
  - cli
  - hcl2json
  - examples
  - readme
  - docs
  - release
  - deps

types:
  - feat
  - fix
  - chore
  - refactor
  - revert

[DanielMSchmidt]

Looking deeper into Semantic release it looks like having one branch for pre-releases and one for releases would be the best supported use-cases. Releasing would mean that we do a PR between the pre-release branch and the main branch.

[DanielMSchmidt]

Another way would be using the exec plugin with a verifyConditionsCmd command that checks if e.g. a tag is set and whatever we need to check as well. The script would abort the release if the condition is not met.

[jsteinich]

Using the full version of Semantic release definitely seems to push towards multiple branches. That seems like it will make sense once there is a 1.0 release (or Terraform type releases), but probably isn't the best right now.
While it may be possible to configure the full version to do what we want, using exec (or even just the release notes generation) might get most of what will be helpful here. Could also look at doing manual release control only (see https://github.com/semantic-release/semantic-release/blob/master/docs/recipes/github-actions.md#trigger-semantic-release-on-demand).

[skorfmann]

Looking deeper into Semantic release it looks like having one branch for pre-releases and one for releases would be the best supported use-cases. Releasing would mean that we do a PR between the pre-release branch and the main branch.

Pretty much what @jsteinich said - this will make sense when approaching 1.0 - Right now I'd keep the workflow rather simple.

I think the biggest pain is really the release notes / changelog generation.

[skorfmann]

Perhaps we should really just focus on the changelog for now. e.g. there's https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-changelog-cli - however, didn't get to consider merge commits only.

Anyone has other tooling ideas to generate changelogs?

[RichiCoder1]

There's a tool by Atlassian for changeset management: https://github.com/atlassian/changesets.
Its release functionality is very NPM specific, but the changeset functionality is generic.

[DanielMSchmidt]

I stumbled upon another option: If we use semantic release beta releases on master we could do the real releases in a github action that does not automatically run, but is triggered manually by us. This way we have control over minor releases and automatic beta releases

[skorfmann]

I stumbled upon another option: If we use semantic release beta releases on master we could do the real releases in a github action that does not automatically run, but is triggered manually by us. This way we have control over minor releases and automatic beta releases

What we're primary looking is two things:

1. Generating a Changelog
2. Bumping the version

The rest is taken care of by jsii-release already. If that fits in the workflow of semantic release that's worth a try.

[DanielMSchmidt]

It does, you can run release tools through a plugin Sebastian Korfmann ***@***.***> schrieb am Mo. 31. Mai 2021 um 10:46:

I stumbled upon another option: If we use semantic release beta releases on master we could do the real releases in a github action that does not automatically run, but is triggered manually by us. This way we have control over minor releases and automatic beta releases What we're primary looking is two things: 1. Generating a Changelog 2. Bumping the version The rest is taken care of by jsii-release already. If that fits in the workflow of semantic release that's worth a try. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#656 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKGNVWIHZHYIHQ7XZKFWZDTQNEFLANCNFSM43KPS5DQ> .

-- Daniel Schmidthe/him Senior Software Engineer - CDK Team e ***@***.*** tz Europe / Berlin (CEST) <http://www.google.com/search?q=current+time+Europe%2FBerlin> ------------------------------ <https://www.hashicorp.com/>

[DanielMSchmidt]

This is solved by #1257 together with the changelog creation script we have in place

[github-actions]

I'm going to lock this issue because it has been closed for 30 days. This helps our maintainers find and focus on the active issues. If you've found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.