Public-health CI jobs produce different results on different agents because tool versions drift. What practice improves consistency?
Select an answer to reveal the explanation.
Short Explanation
You can make public-health builds repeatable by using containers as a sealed lab kit, with the same pinned tools on every agent. Letting local compilers drift, permanently changing host systems, or relying on email alone leaves room for different results.
Full Explanation
Running build and test jobs inside container images that pin the toolchain improves consistency because each agent uses the same defined compilers, runtimes, and utilities. The image becomes a reviewable artifact, reducing “works on my agent” failures and supporting reproducible public-health software builds. Letting each agent keep whatever compilers happen to be installed locally fails because unpinned host tools can diverge over time, producing different results for the same commit. Banning containers and requiring every job to mutate the host OS permanently also fails: persistent host changes create drift, complicate hardening, and couple unrelated jobs through shared state. Documenting tool versions in email without pipeline enforcement is insufficient because email does not prevent an agent from running a different version. Exam caveat: Pin image digests or immutable tags, and rebuild on a schedule; a floating “latest” tag can reintroduce drift. Practical check: Run the same build on two agents with the pinned image, verify that tool versions match inside the container, and fail jobs that use the bare host toolchain instead of the approved image.