build-sys: Rework to have toplevel Dockerfile + Justfile

[cgwalters]

This is aligning with what I did in ostreedev/ostree#3439

• What gets invoked in e.g. GHA should ideally most be just commands that are easy to run locally too (with sudo in GHA, without sudo locally)
• Move the "core build" to the toplevel so that one can just podman build directly too (without the Justfile) and have it do something useful
• The "always build and test in a container" helps for LLM-assisted coding because what they can do is inherently sandboxed

[gemini-code-assist]

Code Review

This pull request introduces a significant and positive rework of the build system, centralizing the core build logic into a toplevel Dockerfile and providing a Justfile for streamlined command execution. These changes align well with the goals of easier local builds and GHA consistency.

The main areas for attention are ensuring that the TMT test environment correctly and efficiently utilizes the new build structure. Overall, this is a solid step forward for the project's build infrastructure.

Summary of Findings

• Duplicated Build Logic in TMT Script: The tmt/tests/bootc-install-provision.sh script now contains duplicated logic for installing build dependencies, which is also present in the main Dockerfile. This should be refactored to follow the DRY principle.
• Potential Impact of Removed File Copy in TMT Script: A COPY instruction for /build/target/dev-rootfs/ was removed from the TMT test image build process. Clarification is needed on whether this directory contained test-critical files and if their absence is intended and safe.
• Dockerfile Image Size Optimization: The main Dockerfile could benefit from adding dnf clean all after package installations to reduce layer size.

Merge Readiness

The pull request makes excellent progress in refactoring the build system. However, there are a couple of high-severity issues related to the TMT test setup that should be addressed to ensure maintainability and correctness: the duplication of build dependency logic and the clarification needed for the removed dev-rootfs copy. There's also a medium-severity suggestion for Docker image optimization.

I am unable to approve the pull request myself. It should be reviewed and approved by other maintainers. I recommend that the high-severity issues identified are addressed before this PR is merged.

[gemini-code-assist]

The heredoc for BOOTCCIEOF (lines 111-135) now includes a RUN block (lines 115-125) that duplicates the build dependency installation logic found in the main Dockerfile (lines 19-29). The TODO comment on line 110 (# TODO use the default Dockerfile here instead of a copy of it) correctly highlights this issue.

To improve maintainability and avoid potential divergence, could we explore ways to consolidate this logic? For example:

• Could the TMT environment leverage the build stage from the main Dockerfile more directly, perhaps by building that target and then using COPY --from to bring artifacts or the prepared source tree into a TMT-specific build stage?
• Alternatively, could the common dependency installation steps be extracted into a shared shell script that both the main Dockerfile and this heredoc can invoke?

Addressing this duplication would make the build process more robust.

[cgwalters]

Yes we need to dedup these, and I think the way to do that will be ensuring the TF flow uses a container built in a registry.

[gemini-code-assist]

The COPY --from=build /build/target/dev-rootfs/ / instruction (and its preceding comment) was removed in this change. While the mkdir -p /build/target/dev-rootfs command still exists in the build stage defined within this script (now on line 127), it's unclear what the purpose of copying files from /build/target/dev-rootfs into the TMT test image was.

If make test-bin-archive or other steps in the build process were populating /build/target/dev-rootfs with files essential for the TMT tests, removing this COPY could potentially lead to test failures or an incorrectly configured test environment.

Could you please clarify:

1. Were files expected to be in /build/target/dev-rootfs?
2. If so, are these files no longer needed in the final TMT image, or is their provision handled differently now?

Understanding this will help ensure the tests remain effective.

[cgwalters]

I intentionally removed test-bin-archive with the goal to no longer copy content built outside the buildroot into it. Instead that use case should derive.

[gemini-code-assist]

To help reduce the final image size of the build stage (and consequently any stages derived from it if they don't clean up themselves), would it be beneficial to add dnf clean all at the end of this RUN instruction block? This would clear out cached package data that's no longer needed after the installations.

dnf clean all

[cgwalters]

OK this one should be ready to review; the testing farm failures on cs9 look like infra flakes.

[p5]

Gave it a quick test, and it works great!

The integration tests are still quite complex to setup locally, so moving this into a container in the long run would be very nice (of course, assuming there's no limitations of containerising these).
I do "dev work" inside a devcontainer which doesn't typically have access to podman/docker, so I need to switch between a host terminal (to access podman/docker) and container terminal (for rust deps) very frequently to run them. Switching is fine, and it isn't like I don't already do this before this PR, but it is something that could be a bit smoother by moving everything to containers.

[p5]

It seems a bit strange to always restrict the number of parallel jobs that can run given this could be ran on workstations with far more resources than a CI runner, though it's a nit.

---

Edit: ah, this is probably bottlenecked by the number of stages in each build, so it's unlikely to ever exceed 4 jobs.
Does this also limit the build to 4 image layers pulled at once?

[henrywang]

All green now.