Build Artifact: The Packaged Output of a CI Run
A build artifact is the packaged result of a CI run, like a compiled binary or a zipped web app. Pipelines use artifacts to pass this output between stages, from building to testing and deploying.
Why it exists
CI/CD pipelines are composed of multiple independent steps or jobs, often running on different machines. To get the output of a 'build' job to a 'test' or 'deploy' job, you need a reliable way to pass files. Build artifacts solve this by providing a formal, managed way to store and retrieve the results of a build.
The mental model
A build artifact is the deliverable from one stage of your software factory to the next. The build stage compiles your code and packages it into a self-contained unit (the artifact). Later stages, like testing and deployment, don't need to know how to build the code; they just consume the finished artifact.
How it works
A CI job compiles code and gathers necessary files (like .dlls, .exe files, or a web app's 'dist' folder). The final step in the job is to 'publish' these files as a named and versioned artifact to the CI/CD system's storage. Subsequent jobs in the pipeline can then 'download' that specific artifact by its name to perform their tasks. This ensures that what is tested is exactly what gets deployed.
When to use it
Use artifacts to pass the state of your application between stages in a CI/CD pipeline. This is the standard practice for separating build, test, and deploy concerns. They are also used to store the final, distributable version of your software for a release, such as an installer or a package for a public registry like npmjs.com or PyPI.
When not to use it
Do not bundle environment-specific configuration or secrets into an artifact. An artifact should be a generic, deployable unit. Configuration should be supplied by the deployment environment at runtime. Also, avoid using artifacts for temporary files that are only needed within a single job; the job's local disk is sufficient for that.
One canonical example
A Node.js web app pipeline. The 'build' job runs 'npm install' and 'npm run build', which creates a '/dist' directory. The job then archives this directory and publishes it as an artifact named 'webapp-1.5.2'. A separate 'deploy' job then starts, downloads the 'webapp-1.5.2' artifact, unzips it, and copies the files to a web server. The key is that the deploy job never runs 'npm' itself; it only works with the verified output from the build job.
Interview question
What type of content is explicitly advised AGAINST including directly within a build artifact?
- a.The final, self-contained package for deployment
- b.The fully compiled and linked executable files
- c.Environment-specific configuration variables or secretsCorrect
- d.The zipped 'dist' folder of a web application
Why? this is the answer
The card explicitly states, "Do not bundle environment-specific configuration or secrets into an artifact." This ensures the artifact remains a generic, deployable unit, with configuration supplied at runtime. The other options describe components that are typically part of a build artifact.
Just read this? Test yourself on what you have been reading.
Read the original → learn.microsoft.com
- #ci/cd
- #build automation
- #devops
- #deployment
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on ci/cd — each one lists the topics its interview covers.
See open roles