build(release): configure semantic release

[C0ZEN]

Some infos:

• Install and configure a workflow to create a release on the master branch
  • Create a tag based on the commits
  • Generate the CHANGELOG.md
  • Set the tag in the package.json and package-lock.json
  • Create a git tag
  • Create a GitHub release
  • Add a comment and a label to each related issue and PR
• Configure the semantic-pull-requests GitHub check
• Configure the release GitHub workflow
  • When a push is done in master
    - Get the current tag
    - Create the release
    - Install the dependencies (use some cache as well)
    - Create the release (see above workflow)
    - Create a new PR from master to main if there is a new tag (so that you can easily merge the changelog and packages changes)
• Configure the alpha release (alpha branch)

What needs to be done before merging (by admin):

• Install the semantic-pull-requests check to disallow to merge a pull request with a bad commit syntax (required to avoid to fail the semantic release)
• Configure the secrets in GitHub

Closes #288

[C0ZEN]

@hross when you have the time if you can take a look 👍🏻.
Hard to test obviously but if you want to keep the stuff safe you can enable the dryRun option in the release config file to ensure that everything is ok.

[hross]

It's going to take me some time to get to this one, especially since it changes the release structure. I will take a look later this week and see if it makes sense (seems cool).

[hross]

I haven't gotten to this one yet. Will look next week.

[hross]

I still like this change but making release modifications requires me to spend a fair bit of time testing and watching and not breaking things so I have not yet merged this.

[hross]

I'm not sure if using angular commit message conventions is the way to go in order to manage the release process. Creating an alpha branch and auto-releasing would be pretty cool but keeping the release process manual means less commit maintenance and lock into the process, plus it's just a tag bump and more of a decision about a major release. Need to think more on this PR.

[C0ZEN]

@hross I am not sure to follow up with the issue.
The alpha branch would be optional in the process but to avoid automated release since you like to test the stuff internally it needs at least a new branch that is why I proposed the master one.
A release in that case is just a PR to merge either on alpha or on master (and is a good place to review the commits to make sure that it will create the tag you wish).
So IMO it's the same process as before except that the tag, the version, the GitHub release and the release notes would be generated based on the commits.
The drawback obviously is that there is a need to have good commits but since everything is squash on this project only the title of the PR matters.

[hross]

I don't think we should do this one for now. I don't want to commit this project to a different release strategy from our other actions right now. Maybe we can come back to it at some point, but for now I'm closing to avoid clutter.