Add release workflow

[SylvainSenechal]

ISSUE: CLDSRVCLT-7

[bert-e]

Hello sylvainsenechal,

My role is to assist you with the merge of this
pull request. Please type @bert-e help to get information
on this process, or consult the user documentation.

Available options

name	description	privileged	authored
/after_pull_request	Wait for the given pull request id to be merged before continuing with the current one.
/bypass_author_approval	Bypass the pull request author's approval	⭐
/bypass_build_status	Bypass the build and test status	⭐
/bypass_commit_size	Bypass the check on the size of the changeset TBA	⭐
/bypass_incompatible_branch	Bypass the check on the source branch prefix	⭐
/bypass_jira_check	Bypass the Jira issue check	⭐
/bypass_peer_approval	Bypass the pull request peers' approval	⭐
/bypass_leader_approval	Bypass the pull request leaders' approval	⭐
/approve	Instruct Bert-E that the author has approved the pull request.		✍️
/create_pull_requests	Allow the creation of integration pull requests.
/create_integration_branches	Allow the creation of integration branches.
/no_octopus	Prevent Wall-E from doing any octopus merge and use multiple consecutive merge instead
/unanimity	Change review acceptance criteria from one reviewer at least to all reviewers
/wait	Instruct Bert-E not to run until further notice.

Available commands

name	description	privileged
/help	Print Bert-E's manual in the pull request.
/status	Print Bert-E's current status in the pull request TBA
/clear	Remove all comments from Bert-E from the history TBA
/retry	Re-start a fresh build TBA
/build	Re-start a fresh build TBA
/force_reset	Delete integration branches & pull requests, and restart merge process from the beginning.
/reset	Try to remove integration branches unless there are commits on them which do not appear on the source branch.

Status report is not available.

[bert-e]

Waiting for approval

The following approvals are needed before I can proceed with the merge:

• the author

• 2 peers

[francoisferrand]

do we really want to push to git?

• this creates releases outside of the development branches
• this is not easily replicated for non-releases, which will makes testing integration more complex
• the repo will not look the same at all for releases & dev, can be quite confusing
• fundamentally, it uses Git as artifact storage.... while there is a dedicated tool: i.e. npm package registries...

→ should we not push to GitHub NPM registry ?
(there is an initial attempt here: scality/Guidelines#206)

[SylvainSenechal]

let's rediscuss after or during daily, i'm not familiar with npm registry, but I feel like the current method is simple and relies and less dependency than having to work with npm

[francoisferrand]

does the "output" of yarn build get cached by setup-node, to speedup rebuilds?
if not, we should implement this kind of caching ourself (using actions/cache)

[SylvainSenechal]

I think for the release.yml, we can do it without caching.
But I've got the same problem in the test file, so I'm gonna check if I can add caching for the tests

[DarkIsDude]

All good for me. Maybe just an update on the README with a new section How to use it but not mandatory. Congrats !