We don't need to test with kustomize, manifest testing is good
enough, as we just test that the manifest are correct, not that
they are functional (which would require a change in the poll time).
This extends our test coverages for kured-* manifest changes on PRs,
and any eventual changes in kubernetes/kubectl on periodics.
Signed-off-by: Jean-Philippe Evrard <open-source@a.spamming.party>
In the past, we had lint issues which were merged into the code,
and/or lint changed without us adapting our code.
This should allow us to stay on top of linting issue by
highlighting them in PRs.
Without this patch, we might hold old issues and PR for a long
time. Instead we should close them. People can reopen if necessary.
This would show that we have a proper triage process, and a proper
way to handle those.
Without this patch, there is no way we can see, in the development
process, if the image we are about to publish is insecure.
This is a problem as we might be releasing new versions of kured
with outdated base image which contains vulnerabilities.
This fixes it by creating a job which will show any eventual
vulnerability.
Without this patch, we don't test on release whether kured actually
works and behave well.
This is a problem, as a functional issue could have been hidden by
a recent change, as our testing is minimalist (only test the
usability, not the functionality).
Instead of testing manually, we should ensure this in CI.
This fixes it by adding a github action which tests the previously
built artifacts before publishing a release. The job consume the helm
chart in our code tree (note: this relies on the last released image),
and run a functional test triggering a coordinated restart of a
whole 5 node cluster deployed with kind, through github actions.
Note: The github action needs to reset docker configuration, else
the reboot of the node (a docker container in kind) will fail.
It will be correctly triggered, but the node will not come back up,
with its systemd log mentioning: "Failed to attach 1 to compat systemd cgroup".
Jean-Philippe Evrard
Daniel HolbachandGitHub
dependabot[bot]andGitHub
Christian Kotzbauer