draft: running tests DO NOT MERGE

[ezopezo]

Running test for containers/buildah#6556 changes.

[packit-as-a-service]

[NON-BLOCKING] Packit jobs failed. @containers/packit-build please check. Everyone else, feel free to ignore.

[nalind]

This will probably be simplified by #27993

[ezopezo]

This will probably be simplified by #27993

@nalind Do you mean this because my errors are including flags that have been implemented elsewhere (like --iidfile-raw, --metadata-file and --source-policy-file)? What is the process for syncing flags that I introduced in buildah repo, but they are absent here? Do I need to extend docs or any other logic in this PR?

[nalind]

This will probably be simplified by #27993

@nalind Do you mean this because my errors are including flags that have been implemented elsewhere (like --iidfile-raw, --metadata-file and --source-policy-file)? What is the process for syncing flags that I introduced in buildah repo, but they are absent here? Do I need to extend docs or any other logic in this PR?

Your changes added new flags, and podman CI is set up to flag some of the additional work that needs to be done to properly integrate them into this repository. Those checks are mainly there so that podman maintainers don't forget to do that work when they refresh the version of buildah that podman uses, but you're getting tripped up by it.

Specifically, podman reuses the CLI flag parsing logic from buildah, and its CI includes scripts that check that options advertised by podman build --help (buildah build will be exposing those options, so podman build will, too) have corresponding descriptions in the applicable podman man pages.

The scripts (./hack/xref-helpmsgs-manpages, invoked during make validate) will complain that snippets describing the new build flags are not present in docs/source/markdown/options with the right directives in docs/source/markdown/podman-build.1.md.in, and possibly docs/source/markdown/podman-farm-build.1.md.in, to cause them to show up in the generated man pages.

CI will likely trip over tests run in configurations where the build command is actually the podman remote client connecting to a podman service and asking the service to do the heavy lifting for a build. That usually requires either wiring things up so that the client supplies input file contents to the server as part of an API request, and writes output files based on results it gets back from the API (as it does for --iid-file), or having the client declare that it doesn't support that flag in remote mode (as it does for --metadata-file), and updating the patch that podman applies to buildah's test script to have it skip a test in that configuration. One step at a time, though.