[CI/CD] Fixes #1301: Created automated release workflow

[birtony]

Issue This PR Addresses

Fixes #1301

Type of Change

• Bugfix: Change which fixes an issue
• New Feature: Change which adds functionality
• Documentation Update: Change which improves documentation
• UI: Change which improves UI

Description

Rebased and updated #1527. This PR adds an automated release workflow for GitHub Actions. It would allow us to create a new release by running npm version (DON'T RUN THIS CODE UNLESS YOU WANT TO MAKE A PRODUCTION RELEASE):

npm version minor -m "Release 1.6.0" 
git push upstream master
git push upstream 1.6.0

The workflow would also run the same checks as our node-js-ci workflow (test, lint, prettier) and generate a changelog to be included in the release.

• commits that follow the pattern will be added to the corresponding sections in the release note. All other commits will be added under 'Other Changes` section.
  https://github.com/lob/generate-changelog#usage

type(category): description [flags]

Where type is one of the following:

    breaking
    build
    ci
    chore
    docs
    feat
    fix
    other
    perf
    refactor
    revert
    style
    test

Example of Generated Changelog:

Example of Workflow Status in GitHub Actions:

How to Test

Create some releases on your forked telescope repository!

• You can test the workflow by merging it into your forked repository and pushing a new tag to it:

git merge upstream/issue1301-create-release-workflow
npm version minor -m "Release 1.6.0"
it push upstream master
git push upstream 1.6.0

• Using GitHub CLI might make it easier to checkout to issue1301-create-release-workflow directly by executing the following:

gh pr checkout 1628

• You can also create a number of dummy commits in your forked repository before creating a new release to see how the changelog is generated.

• We currently use a fairly simple regex to check the pattern of the semantic version. The recommended regex is outlined on semver repository, but it cannot be used in YAML files (some special characters might not be supported in YAML, such as the colon (:), for instance).

Checklist

• Quality: This PR builds and passes our npm test and works locally
• Tests: This PR includes thorough tests or an explanation of why it does not
• Screenshots: This PR includes screenshots or GIFs of the changes made or an explanation of why it does not (if applicable)
• Documentation: This PR includes updated/added documentation to user exposed functionality or configuration variables are added/changed or an explanation of why it does not(if applicable)

[birtony]

Currently, GitHub does not seem to provide an easy way to postpone the execution of one workflow until the other one succeeds. In this PR I have used https://github.com/lewagon/wait-on-check-action to try to integrate a workaround. However, I could not achieve it work properly for every case. In addition, it does not seem to be a too efficient solution as it makes a call to check the status of the other workflow every time the interval expires. It would be great not to have to run rest/lint/prettier on the exact same version of code twice, but it looks like it might be the best solution for now. Please, feel free to share your opinions below.

CC @manekenpix @humphd @PedroFonsecaDEV @HyperTHD

[humphd]

I would do the simple thing and just duplicate the lint/test steps in the release. It doesn't matter that it's duplicated. Passing the tests twice is more proof that production isn't going to get code that can't be built.

[birtony]

I would do the simple thing and just duplicate the lint/test steps in the release. It doesn't matter that it's duplicated. Passing the tests twice is more proof that production isn't going to get code that can't be built.

Yeah, that makes sense. I will proceed to incorporate that logic into this PR.

[chrispinkney]

I think this is good, or at least it seems like it's functioning as expected.

🤤 🤤 🤤 🤤

[birtony]

Updated the workflow to remove the package version bump action. We should use npm version to generate a release as described in the updated description to this pr.

[humphd]

Do you want to add preversion to our package.json script to run npm test? I think that's a logical approach.

[HyperTHD]

LGTM. Can't wait to see this in action later this week. I do agree with adding pre-version. Extra crisp test case passing won't hurt

[birtony]

@humphd @HyperTHD agreed. Let land this one first and take care of that in a subsequent PR. I will take care of it.