Improve automation

[flavio]

First of all, sorry about the big PR. This is something I always try to avoid, but in this case many things had to be changed at the same time to produce a stable environment.

The purpose of this PR is to set the foundation for all the refactoring/improvement work we have to do on the operator.
To achieve that, the following areas have been touched.

Code quality

• Ensure the unit and integration tests can be run by developers on their workstations. Prior to this PR the associated make target exited with an error.
• Enforce coding style guidelines by using golangci-lint. The linter can now be run locally using a dedicated make target
• Ensure tests (unit, integration) and linters are run on each PR and on the main branch: this is done via GitHub actions

Automation

Prior to this PR, there was just one GitHub action that took care of building the container image and publishing the helm chart. No unit tests were involved during the whole process.

This PR removes the old GitHub action and introduces several ones.

I've tested all these changes against my personal fork. I'll share links to some examples below.

Note: these actions have been taken from the kubewarden project. This is a CNCF project I maintain. I've done some minor changes to adapted them to kwasm's needs.

Security improvement

All the GitHub actions are now referenced by their shasum. This provides a better security posture. Next to the shasum, there's a comment stating the "human" tag of the action. Dependabot can keep both information (shasum, human tag) in
sync.

Dependabot

dependabot configuration file was not correct. This prevented the bot from making PRs.

This should be fixed now and we should start receiving PRs about Dockerfile, GitHub Actions and Go dependencies updates.

Testing

As stated before, Unit and function tests, plus linters are now run on PR and each change done to the main branch.

A release won't happen if the tests are not passing. However, a PR could still be merged with broken tests; this is something we can change once this PR is merged.

You will see the tests in action against this very PR. You can see them against a smaller PR here (guess what is coming with another PR once this one gets merged 😄).

Note: the release drafter action against this PR will fail because it requires a file a configuration file that is not yet into the main branch. After this PR is merged everything will be fine.

Container image building

The container image will be built only from the contents of the main branch or with the contents referenced by a tag that follows the v* naming convention.
Prior to this commit, images were built also for PR branches, which caused issues like #31

The following tags are going to be used:

• latest: rolling tag pointing to main
• v<version>: a tagged release of the operator

Prior to this change the stable releases had a really long (and a bit strange IMHO) tag: :kwasm-operator-<version>.

SBOM generation

As part of the release process, SBOM files are generated for the container images (x86_64, arm64).

The SBOM files are generated using syft.

Sigstore integration

Each artifact produced by the automation pipeline (container images, SBOM files) are now signed by cosign, a tool of the Sigstore project.

Signing is done using Sigstore's keyless mode. This produces a series of OCI artifacts inside of the registry where the container image lives.

You can see them here, inside of my fork. The signatures have tags that start with sha256:<something>.

Changelog generation

Release drafter is now used to automatically build a changelog of the upcoming release.

The changelog is built by looking at the commits subjects. As a result of that, it would be great to have all the contributions follow git semantic commits guidelines. We should probably document that into the
contribution guidelines.

GitHub Release

A GitHub release will be created whenever a v* tag is pushed. The name of the GitHub Release will be v<version>.

The GitHub release will contain the information generated by the release-drafter action.

The release will also feature several artifacts like the SBOMs and the signatures of the container images (+ SBOMS). These can be used by end users to verify the integrity of all the assets we produce inside of our release pipeline.

Prior to this commit, no GitHub Release was created for the operator itself. There was just one release for the helm chart.

You can see a fake release that was created on my fork over there:

• GitHub action handling the release
• GitHub release

Note: the changelog isn't really fancy right now because nothing significant happened on my fork, hence release drafter didn't have that much to say.

Helm chart release

When the contents of the charts/ directory are changed, the GitHub action will create a new GitHub release called kwasm-operator-chart-<version>. This is done to differentiate it from the GitHub Release of the operator.

The action creates also a git tag named kwasm-operator-chart-<version>. Before this tag was named
kwasm-operator-<version>.

You can see examples of that on my fork:

• GitHub Release of the helm chart

[shivaylamba]

Amazing work

[0xE282B0]

LGTM.

[0xE282B0]

Changes were too complex to rebase, had to squash PR.