podman buildx inspect #26232

2004joshua · 2025-05-29T13:40:29Z

I added support for "podman buildx inspect". The goal was to replicate "docker buildx inspect" as much as possible but a problem encountered was podman doesn't use docker's Buildkit so to replicate the output I resorted to printing the statements. I used the default names docker used for its output but changed the driver name to podman. Since there was no Buildkit I picked "N/A" as a viable option to describe the version of Buildkit being used. I used the Emulated Architectures + Host Architecture as the supported platforms, when running podman in remote mode it will only return the Server Architecture. The --bootstrap flag was also added, its purpose was to make sure the builderkit container is running before you inspect but since there is none I considered it to be a NOP flag. I also added an extra field to the HostInfo struct so I am able to get the emulated architectures through the engine so a new field to podman info was also introduced as a result.

Fixes #13014

Does this PR introduce a user-facing change?

yes

openshift-ci · 2025-05-29T13:40:36Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: 2004joshua
Once this PR has been reviewed and has the lgtm label, please assign baude for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

cmd/podman/images/buildx_inspect.go

baude · 2025-05-29T13:58:30Z

cmd/podman/images/buildx_inspect.go

+	}
+
+	fmt.Printf("Name:   %s\n", out.builderName)
+	fmt.Printf("Driver: %s\n", out.driverName)


is there ever going to be a need for formatted output (like json?)

No, the way docker does it is they also use prints

I dont think that makes it "right" . @Luap99 you have kind of become the defacto fmt guy on the team, would you prefer we use structs and templates or OK with this?

I think a template would be nicer but I don't care that much.

cmd/podman/images/buildx_inspect.go

test/e2e/buildx_inspect_test.go

cmd/podman/images/buildx_inspect.go

jankaluza · 2025-05-30T11:35:34Z

test/e2e/buildx_inspect_test.go

+		Expect(output).To(MatchRegexp(`Platforms:\s+.*\b` + regexp.QuoteMeta(expectedNativePlatform) + `\b`))
+	})
+
+	It("podman buildx inspect", func() {


Great that you introduced tests for this change :-).

I think there's a some duplicated code here:

Native platform parsing

Emulated Architectures parsing

Expected Platform assertions

Maybe you could move these to separated functions and reuse them to make the tests easier to read and also edit in the future if we change the way how this command behaves.

I agree it is quite hard to read the tests due the duplication.

Luap99

Welcome to the team, I am not familiar with docker buildx output so I cannot comment on the specifcs there so these are mostly general style comments.

Luap99 · 2025-05-30T14:26:46Z

cmd/podman/images/buildx_inspect.go

+	if registry.IsRemote() {
+		runtimeOS := infoReport.Host.OS
+		runtimeArch := infoReport.Host.Arch
+		defaultNode.Platforms = []string{fmt.Sprintf("%s/%s", runtimeOS, runtimeArch)}


Why is this not using infoReport.Host.EmulatedArchitectures? The build will happen on the remote system so listing th elocal arch of the client seems not correct?

The reason I didn't include emulation.Registered() for remote builds was because the build tag in emulation.go had //go:build !remote so there wasn't a way to get those emulated archs. It also doesn't list the arch of the client it give you the remote system arch.

I think we want the remote system's architectures, though? The build happens on the server, so we should be reporting what the server can do?

Luap99 · 2025-05-30T14:28:08Z

cmd/podman/images/buildx_inspect.go

+	ctx := cmd.Context()
+
+	infoReport, infoErr := registry.ContainerEngine().Info(ctx)


for consistency the rest of the cli code uses registry.Context() so this should to.

added this change

Luap99 · 2025-05-30T14:30:26Z

cmd/podman/images/buildx_inspect.go

+	infoReport, infoErr := registry.ContainerEngine().Info(ctx)
+
+	if infoErr != nil {
+		return fmt.Errorf("retrieving podman engine information: %w", infoErr)
+	}


As general rule unless you must store the error for latter go error variables are generally called err and there is no newline between the call and if err != nil { return err} branch. Second, I would remove the word "engine" from the error. We don't say podman engine.

Luap99 · 2025-05-30T14:36:57Z

test/e2e/buildx_inspect_test.go

+		if !registry.IsRemote() {
+			Skip("This test is only applicable for remote podman")
+		}


Why are these skipped on remote? Looking at the podman code the command has a branch for if remote but it should work fine. All tests here skip on remote which means the IsRemote() condition in the actual comman is never executed.

Second calling registry.IsRemote() is actually incorrect from test context and doesn't do what you want. If you really have to skip on remote one must use SkipIfRemote() which uses IsRemote from the e2e package. Notice how this is using the remote_testing build tag to switch the behaviour. registry.IsRemote() passes cli arguments which makes no sense in the context of ginkgo tests.

Luap99 · 2025-05-30T14:37:53Z

test/e2e/buildx_inspect_test.go

+		Expect(output).To(MatchRegexp(`Platforms:\s+.*\b` + regexp.QuoteMeta(expectedNativePlatform) + `\b`))
+	})
+
+	It("podman buildx inspect", func() {


I agree it is quite hard to read the tests due the duplication.

Luap99 · 2025-05-30T14:38:43Z

test/e2e/buildx_inspect_test.go

+		stdErr := session.ErrorToString()
+		Expect(stdErr).ToNot(MatchRegexp(`(?i)error starting|fail|fatal|panic`), "stderr should not contain critical error keywords, got: %s", stdErr)


this is not checking anything ExitCleanly() verifies already that there is not stderr output so there is no reason to regex check any of its output.

Luap99 · 2025-05-30T14:43:00Z

test/e2e/buildx_inspect_test.go

+		backendHostOS := strings.TrimSpace(hostOSSession.OutputToString())
+		Expect(backendHostOS).ToNot(BeEmpty())
+
+		emulatedArchsNamesSession := podmanTest.PodmanExitCleanly("info", "--format", "{{.Host.EmulatedArchitectures}}")


you can use {{json .Host.EmulatedArchitectures}} which gives you a json array and then just json.Unmarshal() the result into a []string which should simplyfy the manual string parsing you are doing here.

Luap99 · 2025-05-30T14:43:10Z

test/e2e/buildx_inspect_test.go

+		stdErr := session.ErrorToString()
+		Expect(stdErr).ToNot(MatchRegexp(`(?i)error starting|fail|fatal|panic`), "stderr should not contain critical error keywords, got: %s", stdErr)


same as above, and same comment on deduplication.

Added support for "podman buildx inspect". The goal was to replicate the default output from "docker buildx inspect" as much as possible but a problem encountered was podman not supporting BuildKit. To replicate the output I resorted to printing the statements with default values but only changed the driver name to use podman instead of docker. Since there was no buildkit, gave it the value of "N/A" to depict it's not supported. For Platforms, I resorted to using the emulated architectures found on your linux system + the host architecture of your local machine or podman server. The bootstrap flag was also added but is considered a NOP since there is no buildkit container to run before running inspect. An extra field was added to the HostInfo struct so when you run "podman info" the emulated architectures will show, this was used so you can grab the information from the podman engine. Fixes containers#13014 Signed-off-by: Joshua Arrevillaga <[email protected]>

mheon · 2025-06-02T18:27:41Z

cmd/podman/images/buildx_inspect.go

+
+func init() {
+	buildxInspectCmd.Flags().Bool("bootstrap", false, "Currently a No Op for podman")
+	registry.Commands = append(registry.Commands, registry.CliCommand{


@Luap99 What would you say about marking this one as hidden? I don't think we necessarily want this in podman buildx --help?

openshift-ci bot added the do-not-merge/release-note-label-needed Enforce release-note requirement, even if just None label May 29, 2025

openshift-ci bot added release-note and removed do-not-merge/release-note-label-needed Enforce release-note requirement, even if just None labels May 29, 2025