feat: add semanatic release setup

[vgarciabnz]

This PR adds the semantic-release setup. Here I am writing a few considerations about the setup that would be good to keep in some place (maybe the repo wiki or the README file).

About the version and the release process:

• Version is not manually maintained anymore. It is always inferred at runtime using Nyx gradle plugin. This plugin is added as a gradle settings plugin.
• Nyx is configured using the default "extended" preset. This preset configures different release types. The two types we are interested in are:
  • main branch: it generates versions such as x.y.z.
  • beta branch: it generates versions such as x.y.z-beta.i.
• Publications:
  • On pull request: there is no publication on pull request, just unit test.
  • Push to beta branch: publication to Sonatype (snapshot) and NPMJS (beta).
  • Push to main branch: publication to Sonatype (central) and NPMJS (latest).
• Commits starting with fix: or feat: will generate new patch or minor versions. Other commits won't generate versions. It means that a commit such as docs: improve description won't generate a new version and there won't be a new publication.

This PR is raised targeting beta branch, which means that snapshot (sonatype) and beta (nmpjs) packages will be published when merged. The published version would be 1.1.0-SNAPSHOT (sonatype) and 1.1.0-beta.1 (npmjs).

[kabaros]

Two suggestions:

• beta and main workflows can be merged? I don't see a difference
• I don't think you need to manage the check for newVersion manually. You can just rely on the status code of running the script and if it's a success (zero), continue. Otherwise, abort.

I think these changes could make the scripts easier to follow.

Suggested change

	name: Beta branch
	on:
	push:
	branches:
	- 'beta'
	jobs:
	unit-test:
	uses: ./.github/workflows/job-test.yml
	check-new-version:
	needs: unit-test
	uses: ./.github/workflows/job-check-new-version.yml
	publish:
	needs: check-new-version
	if: ${{ needs.check-new-version.outputs.isNewVersion == 'true' }}
	uses: ./.github/workflows/job-publish.yml
	secrets: inherit
	name: publish
	on:
	push:
	branches:
	- 'beta'
	- 'main'
	jobs:
	unit-test:
	uses: ./.github/workflows/job-test.yml
	check-new-version:
	id: checkNewVersion
	needs: unit-test
	run: sh ./.github/workflows/check-new-version.sh
	publish:
	needs: check-new-version
	if: steps.checkNewVersion.outputs.status == 'success'
	uses: ./.github/workflows/job-publish.yml
	secrets: inherit

[vgarciabnz]

Thanks for the comment @kabaros.

• Totally agree on the first point. Those workflows were different at the beginning; they ended up with the same structure and I forgot to remove one of them.
• About the second point, it would be easier just to check for a failure as you suggested. The only reason why I preferred to check the output was to make the step not fail when the version has not change. The overall result would be the same (the version won't be published), but the "check-new-version" step will be colored in red, which could be considered a false positive because it is not an error, it is a valid. What do you think? I am not a pro with Github actions, maybe there is another way to deal with it

[kabaros]

Would it be colored red, even if `continue_on_error` is set to true?

…

On Tue, 6 Feb 2024, 07:41 Víctor García, ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In .github/workflows/beta.yml <#46 (comment)> : > +name: Beta branch + +on: + push: + branches: + - 'beta' + +jobs: + unit-test: + uses: ./.github/workflows/job-test.yml + + check-new-version: + needs: unit-test + uses: ./.github/workflows/job-check-new-version.yml + + publish: + needs: check-new-version + if: ${{ needs.check-new-version.outputs.isNewVersion == 'true' }} + uses: ./.github/workflows/job-publish.yml + secrets: inherit Thanks for the comment @kabaros <https://github.com/kabaros>. - Totally agree on the first point. Those workflows were different at the beginning; they ended up with the same structure and I forgot to remove one of them. - About the second point, it would be easier just to check for a failure as you suggested. The only reason why I preferred to check the output was to make the step not fail when the version has not change. The overall result would be the same (the version won't be published), but the "check-new-version" step will be colored in red, which could be considered a false positive because it is not an error, it is a valid. What do you think? I am not a pro with Github actions, maybe there is another way to deal with it — Reply to this email directly, view it on GitHub <#46 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHXXRIJ4RYEPV4L6TWT47DYSHNEFAVCNFSM6AAAAABC2EFCDCVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTQNRUGQ3DEMRYG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[vgarciabnz]

umm... good point, let me try that

[vgarciabnz]

After a call with @kabaros we decided to consolidate "beta" and "main" workflows in the same file and to keep the version validation as it was before. The PR is updated with these changes, so ready it would be ready when it comes to these comments.