chore(ci): Use Github Actions and Semantic Release

[tumido]

Resolves #70
Complementary CI part to #77

Supported workflows (all demos linked below include an additional drop me commit - I needed to point my fork to my personal quay account)

Pull request

On a new pull request attempt to test (via npm test) and build the controller (s2i build, using .s2ibase file content for builder image) and peribolos (from Dockerfile)

Links:
tumido#15
https://github.com/tumido/peribolos-as-a-service/actions/runs/2260924150

Push

On each push to main run a similar check as for pull request with addition of pushing both containers to quay. Images are labeled as latest as well as by commit hash.

Links:
tumido@0439360
https://github.com/tumido/peribolos-as-a-service/actions/runs/2260912052

Release

Triggered from issue template labeled as kind/release. At first it checks if the issue author has write permission to the repo to establish if it's maintainer who triggered it. Then it does the same checks as for PR (test + build both). If successful it uses semantic release to identify if release is needed. If so, it generate changelog (update CHANGELOG.md), bump package.json and package-lock.json versions and update image pointers in stage to the future release. Then it pushes the changes to main and creates a tag matching the new version. After that it checkouts the new tag and builds (using the same strategies as in above mentioned workflows) and pushed both container images to quay. Pushed images are labeled by the tag and commit hash. All progress is reported in the release issue in a comment. If whole release was successful, issue is closed.

Links:
https://github.com/tumido/peribolos-as-a-service/issues/16
https://github.com/tumido/peribolos-as-a-service/actions/runs/2260978488
tumido@d7a9366

Promote stage images to prod

Triggered from issue template labeled as kind/promote. At first it checks if the issue author has write permission to the repo to establish if it's maintainer who triggered it. If so, it uses yq to get images list from stage/kustomization.yaml and inject it into prod/kustomization.yaml. Then it proceeds to create a PR from it, linking back to the original issue. All progress is reported in the release issue in a comment.

Links:
https://github.com/tumido/peribolos-as-a-service/issues/17
https://github.com/tumido/peribolos-as-a-service/actions/runs/2261016095
tumido#18

Shortcommings

Only gap in the whole process is promotion of the new release to stage, where there might be a 1-2 min window between the images being available on quay, while the updated staging manifests are already in the repo - which kinda make sense, since we should not have images public before the revision is even tracked in VCS...

Future work

• Set expiration tag on images labeled by commit hashes - leave forever only latest + releases.
• Periodic rebuilds.

[sesheta]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[harshad16]

Why do we not wanna use our own tools? if you feel there is something lacking from the tools can you share them with me, please? I understand it could be a personnel choice.
I just wanted to know what is lacking that makes customers choose another tool, so we can make our own tools better.

[tumido]

Why to create own tools when something like semantic-release is here, works so well in Node.js ecosystem it is readily available, extensible, configurable through package.json etc?

AICoE-CI is lacking in many ways and while it may be useful for certain Python flows, it needs to be either heavily extended or modified to support other usecases - like Node.js.

This PR allows us:

• Trigger from a Github Issue for release and stage promotion
• It bumps manifests as well as package.json version on releas
• It can decide automatically if there's enough content for a release and if it should be mayor, minor, patch release - using semantic commit messages.
• It generates changelog and propagates it to Changelog.md as well as Github Release
• It labels all issues included in a release as released
• It can build multiple container images (controller and peribolos) at the same time - one as S21, other from Containerfile, image tags are synchronized, both images are labeled the same
• It builds and pushes for each merge tagging the commit hash + moving the latest tag
• It runs npm test
• It provides feedback on what it's currently doing (see here for an example) which AICoE-CI choose not to implement Add a /debug command to see what the bots know about a particular issue/PR AICoE/aicoe-ci#89 This is a big thing for me.
• It can use credentials from repository secrets
• It can add extra tags to images based on variables, doesn't have to be hardcoded.
• It will allow us (not yet in the PR) to fully customize things like expiring images and periodically rebuilding for security them since we use base/builder images that are moving targets and receive security updates.
• Build logs are readily available in a single click via a Checks and Actions.
• Builders are running from this repository using the node version we choose them to run. The version used by CI is always in sync with what the repo expects.

I think the semantic release and GitHub Actions ecosystems are very well made and polished and easy to use. No need to recreate it in AICoE-CI if we can just pick it up and use it.

These are just some initial thoughts from top of my head why I wanted to use this here and why I chose to use the same set of tools before for slack-first and other projects of mine.

[harshad16]

Thank you for the elaborate explanation. This is good to know 👍

[tumido]

@mimotej @harshad16 PTAL

[mimotej]

Looks great! And I agree with stated above AICOE-CI is mainly focused on Python workflows and it would need changes to properly support Node.js, so it is better to use other tools :) .

[harshad16]

lgtm
thanks 💯

[sesheta]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: harshad16

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [harshad16]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[github-actions]

🎉 This PR is included in version 1.0.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀