Build artifact
The frozen file, bundle, binary, or image a build produces and later deploys. Build it once, then move those exact bytes toward production.
What it is
A build artifact is the frozen output of a build: a Java JAR, a compiled binary, a tarball of browser assets, or a container image. Source code goes in once, the build runs once, and the resulting bytes get a version or content digest so they can be stored, tested, and deployed without changing underneath you.
Reach for artifacts when a release moves through several environments. CI should build once, put the result in an artifact registry, then promote that exact object from test to staging to production. That is what makes a passing staging check evidence about the thing production will run.
Gotcha: rebuilding from the same commit is not guaranteed to produce the same bytes. Dependency ranges, timestamps, base image tags, and build environment differences can all change the output. Treat the artifact as immutable, record its SHA-256 digest, and deploy by that identity instead of a moving tag such as latest.
Ask AI for it
Create a GitHub Actions build job that installs dependencies from the lockfile, runs the production build once, packages the output as a tar.gz archive, computes its SHA-256 digest with sha256sum, and uploads it with actions/upload-artifact using retention-days: 14. Make every later test and deploy job download that same archive with actions/download-artifact and verify the recorded digest before using it. Name the artifact with the git commit SHA and never rebuild from source inside a deploy job.