Update of GitHub Actions Workflows

[pplancq]

This PR introduces several updates to our workflows for GitHub shares.

1. Release workflow update: The release workflow has been updated to incorporate semantic-release. This workflow is manually triggered, allowing you to release a new version when you feel the master branch is stable and ready for release. The process is then fully automated, handling the generation of the new version number, creation of the changelog, updating of package.json, npm publishing, git tagging, and even publishing to GitHub. ⚠ However, for this to work correctly, it is imperative to add the v4.0.10 tag to commit 475edb427a3e8c708719cb3dd6b6d5aac3b5012f.

2. Build workflow modification: The build workflow has been modified so that commitlint only runs once.

3. Stale Action Update: The stale action has been updated to automatically close issues and/or PRs that are no longer updated.

I've made this change to make maintenance easier for you, and I hope you'll find it useful.

We welcome your comments and feedback.

fix #195

[bencompton]

Thanks, the ability to release manually in the shorter term is perfect, and stale issue automation is also something I've been meaning to get working for quite some time!

[bencompton]

@pplancq - apologies, from reading your comments and looking at the code in this PR and your 'dev-tools' repo, I'm still not quite clear on how the manual release process works. Is it now looking for a specific commit message pattern, like 'Release v4.0.10'?

[pplancq]

Apologies, I forgot to explain how it works .

To paraphrase Apple, "it's magic" 😊.

To put it simply, all you have to do is write your commits correctly, respecting the conventional commit. When you decide that the master can be released, all you have to do is manually launch the release workflow from github.

Then semantic-release will retrieve the last git tag, then the commits since the last tag, and depending on the type of commit, it will determine the new version as follows:

• type fix, chore, docs, styles, test, perf or refactor it increments the patch version
• type feat it increments the minor version
• and the commit contains BREAKING CHANGE it increments the major version

I've seen that you've added the 4.0.10 tag, so normally if you run the workflow on the basis of the commits, it should generate version 4.0.11. Right now I'm working on a small feature, as my commit will be of the feat type, it will generate vesion 4.1.0 and so on.

I hope this answers your questions

[pplancq]

Also, if you restart the release workflow just after making a release, semantic-release will see that no new commit has been made since the last tag, so it won't do anything.

[bencompton]

However, for this to work correctly, it is imperative to add the v4.0.10 tag to commit

Ah, run the workflow manually. Based on your statements above, I was thinking it was based on commits with some magic code somewhere. 😆

[pplancq]

My apologies for the confusion. I asked for the 4.0.10 tag to be added so that semantic-release could take over the numbering from there.

Without this tag, there is a risk of conflict with npm because the last tag was version 4.0.1 and semantic-release can generate a version 4.0.4.

By using this 4.0.10 tag, semantic-release can generate version 4.0.11, 4.1.0, or even 5.0.0 when the release workflow is launched. The version number is determined solely by the type of commit (feat, fix, etc.).

I hope this explanation will reassure you about how it works. I've made releasing a new version extremely simple for you, with the aim of saving you as much time as possible 😀

[github-actions[bot]]

:tada: This PR is included in version 4.1.0 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket: