Simplify license compliance workflow by replacing the custom Perl
scripts with the go-license utility, already used by Icinga
Notifications and Icinga Kubernetes[0,1].
Afterwards, we will have (almost) identical compliance.yml workflows for
all of our Go repositories, with only the Go module name and allowed
licenses varying.
[0]: 272ecf231f/.github/workflows/compliance.yml
[1]: de88147599/.github/workflows/compliance.yml
Add a new section to the documentation about installing in containerized
environments. Also, add a GitHub Action that pushes this new section to
Docker Hub to display it as the container README.
After bumping the Go version to 1.24.1, the staticcheck-action fails
since it is outdated. No update is available. However, since staticcheck
is enabled by default in the golangci-lint action, it can be removed.
To ensure the workflow is reusable across our repositories, it must support
releasing from different release trains, such as when issuing bugfix or
security releases for older versions alongside newer ones. This change
introduces custom logic to determine when to apply the latest tag and major
version tags. The docker/metadata-action unconditionally applies these tags,
which could override existing greater tags. The new logic compares the current
release tag against all existing tags using semantic versioning rules, a
feature not inherently provided by docker/metadata-action.
Use the checkout action explicitly to fetch all tags, rather than relying on
docker/build-push-action's implicit checkout. This allows us to implement
custom logic for tagging as 'latest' and with the appropriate major version
when applicable.
This workflow builds and publishes container images directly from this
repository. Here is a summary of its initial setup for reference:
The Build and Publish Container Image workflow builds container images and
pushes them to both GitHub Container Registry (GHCR) and Docker Hub. It sets up
QEMU and Docker Buildx for cross-platform builds, and builds the container
images using the Containerfile. Upon pushes to the main branch or when releases
are published, it logs into GHCR and Docker Hub using credentials from GitHub
secrets, tags and pushes the images to both registries, and generates and
pushes signed build provenance attestations to each registry. The workflow also
triggers for pull requests to the main branch, verifying only the image build.
The workflow using https://github.com/Icinga/docker-icingadb for building and
publishing container images is now obsolete. We will replace it with a new
workflow that builds and pushes container images directly from this repository.
According to "go tool compile", the "-m" flag results in "print[ing]
optimization decisions". Those are shown on GitHub PRs as errors.
In my opinion, this behavior is misleading and has no real benefit.
Running only weekly just adds latency until PRs are created with no apparent
benefit. Multiple releases within a week for the same module happen rarely, so
it doesn't reduce the number of PRs.
For me personally, I receive notifications for the creation of the PRs anyways,
so the extra review request provides no benefit to me. I also asked the others
and they don't see a need either. Therefore, there's really no reason to
maintain this list here.
This check turned out to be not very helpful. Typically, you will first
increase the version number in the source, make it a PR, review it, merge it
and only aftewards, tag the version. In this PR, the check is always
complaining if you did not forget to do something.
There was a mix of diferent action and Go versions specified throughout the
GitHub Actions workflow configs. In general, we want to be compatible with the
latest Go 1.x version, so just specify that instead of bumping versions
everywhere when necessary.
At the same time, bump the actions/setup-go to v4, the latest currently
available version. This prefers versions already cached on the runner and
enables automatic caching for dependencies.
dependabot adds a link showing the diff of the dependency but when there are
changes in indirect dependencies, these have to be diffed manually. This commit
vendors the dependencies before and after a PR and outputs the diff.
If I remember correctly, some time ago you were able to download artifacts from
the job page, i.e. there was no issues with two jobs using the same artifact
name within one workflow. Now it looks like you can only download the artifacts
from the workflow page, so this commit allows you to download both files from
there.
