Remove go-makefile-maker and continue with a custom Makefile#397
Draft
felix-kaestner wants to merge 1 commit into
Draft
Remove go-makefile-maker and continue with a custom Makefile#397felix-kaestner wants to merge 1 commit into
felix-kaestner wants to merge 1 commit into
Conversation
felix-kaestner
force-pushed
the
chore/drop-gomm
branch
2 times, most recently
from
82ad7cf to
abb4839
Compare
felix-kaestner
commented
Jun 4, 2026
| // Set runtime concurrency to match CPU limit imposed by Kubernetes | ||
| _ "go.uber.org/automaxprocs" | ||
|
|
||
| "github.com/sapcc/go-api-declarations/bininfo" |
Contributor
Author
There was a problem hiding this comment.
Removing such SAP-specific dependency from the project seems like the right path for a ApeiroRA project that has the desire to be openly and independently governed.
At the current point of time, we have disabled most of the features go-makefile-maker brings, like Dockerfile, REUSE, Nix, custom golangci-lint configuration and GitHub Action workflow generation due to customizations we like to perform ourselves. Additionally, go-makefile-maker unconditionally generates files like a Renovate configuration and a CodeQL workflow that are not wanted in this project: we use Dependabot for dependency updates and CodeQL is enabled as a repository-wide setting that runs automatically without a dedicated workflow file. When running the tool, a contributor would have to know to discard these unwanted files before committing, which makes the experience cumbersome. The remaining scope of go-makefile-maker in this project has been reduced to generating lint, test and build targets for a controller-runtime based project, along with a handful of install-* targets for tooling. However, the `verbatim` section of the setup has grown to a size where the majority of the Makefile targets come from custom code anyway. As a result, it feels like the right approach to remove go-makefile-maker and go forward with a custom Makefile, based on kubebuilders Makefile. This gives us the flexibility to adjust and extend Makefile targets in the future and removes yet another dependency used by the project that contributors will have to know/learn to be able to contribute. Another advantage of the kubebuilder-style Makefile is that it pins all tool dependencies to explicit versions (e.g. kubebuilder v4.13.1, controller-gen v0.20.1, golangci-lint v2.11.4). The previous setup installed tools with the latest version, which has caused CI breakages in the past when a new incompatible release of a tool was published. Pinning versions makes builds reproducible and prevents unexpected failures in CI. This comes at the cost of manually maintaining related files. Closes #6 Signed-off-by: Felix Kästner <felix.kaestner@sap.com>
felix-kaestner
force-pushed
the
chore/drop-gomm
branch
from
abb4839 to
7de24a7
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
At the current point of time, we have disabled most of the features go-makefile-maker brings, like Dockerfile, REUSE, Nix, custom golangci-lint configuration and GitHub Action workflow generation due to customizations we like to perform ourselves. Additionally, go-makefile-maker unconditionally generates files like a Renovate configuration and a CodeQL workflow that are not wanted in this project: we use Dependabot for dependency updates and CodeQL is enabled as a repository-wide setting that runs automatically without a dedicated workflow file. When running the tool, a contributor would have to know to discard these unwanted files before committing, which makes the experience cumbersome.
The remaining scope of go-makefile-maker in this project has been reduced to generating lint, test and build targets for a controller-runtime based project, along with a handful of install-* targets for tooling. However, the
verbatimsection of the setup has grown to a size where the majority of the Makefile targets come from custom code anyway.As a result, it feels like the right approach to remove go-makefile-maker and go forward with a custom Makefile, based on kubebuilders Makefile. This gives us the flexibility to adjust and extend Makefile targets in the future and removes yet another dependency used by the project that contributors will have to know/learn to be able to contribute.
Another advantage of the kubebuilder-style Makefile is that it pins all tool dependencies to explicit versions (e.g. kubebuilder v4.13.1, controller-gen v0.20.1, golangci-lint v2.11.4). The previous setup installed tools with
@latest, which has caused CI breakages in the past when a new incompatible release of a tool was published. Pinning versions makes builds reproducible and prevents unexpected failures in CI.This comes at the cost of manually maintaining related files.
Closes #6