Skip to content

feat: generalize container tool usage in Makefile template #6932

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

rhuss
Copy link

@rhuss rhuss commented May 10, 2025

Description of the change:
This PR generalizes the container tool usage in the bundle build target to respect the CONTAINER_TOOL variable. The change replaces the hardcoded docker command with $(CONTAINER_TOOL) in the bundle-build target of the Makefile template, making it consistent with other container-related targets in the operator-sdk.

Motivation for the change:
Currently, the bundle build target hardcodes the use of docker as the container tool, which is inconsistent with other parts of the operator-sdk that respect the CONTAINER_TOOL variable. This change:

  1. Makes the bundle build process more flexible by allowing users to use alternative container tools like podman
  2. Maintains consistency with the rest of the operator-sdk tooling
  3. Follows the existing pattern used in other container-related targets

Checklist

If the pull request includes user-facing changes, extra documentation is required:

Copy link
Contributor

@camilamacedo86 camilamacedo86 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @rhuss

Thank you for your contribution 🥇

I think that is OK because matches with the scaffold of kubebuilder: https://github.com/kubernetes-sigs/kubebuilder/blob/master/testdata/project-v4/Makefile

However, you need to run make install and make generate locally to ensure that those files are properly updated in the testdata.

@rhuss rhuss force-pushed the feat/generalize-container-tool branch from 9566ad4 to 1a11e7c Compare May 14, 2025 06:41
@rhuss
Copy link
Author

rhuss commented May 14, 2025

Thanks! Regenerated makefiles now.

@rhuss
Copy link
Author

rhuss commented May 14, 2025

For non-go Makefiles the $CONTAINER_TOOL needs to be included in the fragment, vor go Makefiles it comes from kubebuilder. Adapted the template accordingly.

@camilamacedo86
Copy link
Contributor

Hi @rhuss

Can you please rebase it with master?
Also, see that it still falling in the sanity checks. You can run make test-sanity

@rhuss rhuss force-pushed the feat/generalize-container-tool branch from 1228903 to 4734c43 Compare May 15, 2025 10:23
@rhuss
Copy link
Author

rhuss commented May 15, 2025

rebased ...

@rhuss
Copy link
Author

rhuss commented May 15, 2025

@camilamacedo86 I've fixed the sanity check, but the doc check fails for some reason, but I'm pretty sure this is not because of this PR.

Signed-off-by: Roland Huß <[email protected]>
@@ -230,6 +230,9 @@ bundle: manifests kustomize operator-sdk ## Generate bundle manifests and metada
`

makefileBundleFragmentNonGo = `
# Container tool to use for building images
CONTAINER_TOOL ?= docker
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe we shouldn't add this code here directly.
The more appropriate approach would be to update the Makefile scaffold used by Helm. You can refer to the implementation here for context:
👉 https://github.com/operator-framework/operator-sdk/blob/master/internal/plugins/helm/v1/scaffolds/internal/templates/makefile.go

Additionally, it would be great if we could add the same logic in the default Golang plugin as well, ideally on the same line. This would help us keep things consistent and easier to maintain across plugins. Could you please take a look?

Lastly, if this change is really needed here, we'd need to ensure it's applied and validated across all relevant places to keep things aligned.

Appreciate your effort—thank you! 😊

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants