Build Artifacts

Build artifacts are immutable outputs produced by a build, such as Java JARs, container images, and build metadata. CI/CD pipelines store and promote these outputs between stages so later stages deploy the same tested artifact rather than rebuilding it.

A build artifact is the concrete result of compiling, packaging, or otherwise processing source code. For a Java backend, common artifacts include a `.jar` file, a container image, generated documentation, and metadata such as checksums or version information.

In CI/CD, artifacts provide a handoff between pipeline stages. A build stage can compile and test the application once, publish the resulting artifact to an artifact repository or container registry, and later stages can retrieve that exact artifact for additional testing or deployment.

Artifacts should generally be treated as immutable. If a JAR identified as version `1.4.2` changes after testing, the artifact that was tested is no longer guaranteed to be the one deployed. A new build should produce a distinct artifact or immutable identifier instead.

Separating building from deployment improves reproducibility. The build environment creates the artifact; deployment environments consume it. This avoids subtle differences caused by rebuilding with different dependencies, compilers, environment variables, or source revisions.

Artifact storage also supports traceability. Useful metadata can associate an artifact with a source commit, build number, dependency set, checksum, and test results, making it easier to determine exactly what code reached an environment.

Key points

• A build artifact is a concrete output of a build process.
• Java applications commonly produce JARs and container images.
• CI/CD stages can publish, test, and promote the same artifact.
• Artifacts should be immutable once published.
• Metadata such as commit IDs and checksums improves traceability.

Interview questions

What is a build artifact?

A build artifact is an output produced by a build process that can be stored and used later. For a Java service, a common example is a JAR file. A container image is another example when the application is packaged for container deployment. CI/CD pipelines can pass these outputs from one stage to another.

Why should a CI/CD pipeline build an artifact once and promote it?

Building once ensures that testing and deployment use the same binary or image. Rebuilding in a later stage can introduce differences in dependencies, toolchains, configuration, or source state. Promoting the tested artifact therefore improves reproducibility and traceability. Each environment can supply its deployment configuration without changing the application artifact.

What information would you associate with a build artifact?

I would associate the artifact with the source commit, version or immutable digest, build identifier, and relevant dependency information. I would also retain verification information such as checksums and test results where appropriate. This metadata helps answer which source produced a deployed artifact and whether the deployed object is the one that passed testing. For container images, an immutable image digest is particularly useful for identifying the exact image.

What problems can occur if an artifact repository allows existing versions to be overwritten?

Overwriting can make a version identifier refer to different binary content at different times. That breaks reproducibility because a deployment that says it uses version `1.2.0` may not identify a unique artifact. It also complicates rollback, auditing, and incident investigation. A better design uses immutable artifact identities and publishes a new identity when the content changes.