Continuous release nos-elements

Context

For now, the current master job on nuxeo-nos-element seems to upload only a tagged (snapshot) version and requires more tooling for releasing and publishing it.

See:
https://github.com/nuxeo/nuxeo-nos-elements/blob/master/package.json#L16
https://mavenin.nuxeo.com/nexus/#browse/search=keyword%3Dnos-studio-elements:204bb0680db639646be4988b4b7533c2 lists only an uploaded artifact Apr 30th and last success build was on May 6th: https://qa.nuxeo.org/jenkins/job/Private/job/NOS/job/nuxeo-nos-elements-master/2/console

I think, it's a good use case to review the current node module/package release process.

Idea

For a proper continuous delivery system, we can assume every commit on master is a release, then we need to differentiate commits done on working branch and master.

We are using lerna to manage multiple packages in the same repository.

It seems to make sense to rely on lerna as well to manage versions and releases publication.

See:

• https://github.com/lerna/lerna
• https://github.com/lerna/lerna/tree/master/commands/publish
• https://github.com/lerna/lerna/tree/master/commands/version

Build Pipeline Proposal

Commit pushed on master

Means release; using lerna version --conventional-commits --yes for incrementing patch/minor/major depending on messages commit (https://www.conventionalcommits.org/en/v1.0.0/)
The result will be a commit incrementing modified package and tagged following pattern vX.X.X

Then, execute lerna publish from-git --yes to publish what has been set lerna version

Then, execute a `jx pr` in `nuxeo/nos/` repository to update nos-element version

Commit on any other branch (aka working branch)

Lerna has a canary publication that allows deploying "working" and "SHA1"-ed release package; without putting a git tag.
Plus, It makes sence to rely on it with a unik per-branch identifier for preventing conflicts:

Execute lerna publish --canary --preid NXP-XXXX, will result to a published version like: 0.2.2-NXP-XXXX.2

We need to define how to resolve from the build pipeline the per-branch identifier.