Releases workflow

We release new versions of the app through Github Actions.

For each push, the CI runs some tests on Linux, then builds the app in both Windows & macOS - all of that in the Build workflow.

If the Build workflow succeeds on the master branch, the Release workflows trigger and publish a draft Github Release for each of the Maap instances. There's one workflow per instance, so each of them can be individually cancelled and/or retried if anything goes wrong.

Since the Release workflows are triggered by a Workflow Run event, Github Actions uses the workflow definition that's on the master branch after the original Build workflow succeeds. This means that changes to the Release workflows made on a branch are not acknowledged until merged into the repo's default branch. The Release workflows take care of checking out the commit the Build workflow was based on (ie, they release whatever app's code the Build workflow worked with).

The Release workflows are all the same - they just change which instance they are building. If you want to change them, edit the release.yml template at the repo's root, and then run yarn run generate-release-workflows to [re-]create the per-instance release workflow file (the ones in .github/workflows/release-XXXX.yml). You have to commit the per-instance files for Github Actions to honour them - editing the template is not enough. And don't forget they have to be on the master branch.

The version number comes from the package.json file.