What does "build artifact" mean in the context of a dockerized development environment?

Question

In a blog post about creating a dockerized development environment there is a section where the following question and first paragraph answer are given:

What type of build artifacts do you want?

The build artifact I wanted in this example was a running container. Either Compose or docker would have been appropriate tools to that end. In your scenario you might prefer to have a distributable image, or you might prefer that the build produce a binary on your host operating system.

I read in another question that an artifact can be anything created during a process. From reading through other answers it seems like the context in which the term is used is important.

In the context of using Docker to create a development environment, what does build artifact mean?

Solution 1

In short I'd say: Environment + Compiled output = Artifact.

That is, the full environment including all tools, dependencies etc. needed to build the source (image), + the actually built/compiled result (runnables/libs), with the latter stored inside the former!

This way, in case of a crash/bug, everything is there for you, ready to be debugged no matter what dusty & old version of your software the issue occurred on. *

_{*: I didn't include source in above description, but that could also be preferable. Otherwise, since we all use version control, it can be mounted afterwards if necessary.}

Artifact vs Image:

(note from comments)

"Artifact" is merely a word for something that is produced; in this context a byproduct when developing software. So the runnables/libs are the artifact(s) produced when compiling source, and the image is the artifact produced by the whole "build"-step, basically an artifact containing one or more other artifact(s)!

This makes more sense when you start working with automated build, test & deployment pipelines (AKA Continuous Delivery).

---

Note 1:

This would be the end-result, thus how you choose to setup any steps up until this point is up to you (split-image approach etc.).

Note 2:

I've just recently started playing with docker in combination with continuous delivery, so these are just my initial two cents :)

Solution 2

In terms of build pipelines in general the Artifact is the software component that is produced during the build, stored in a repository and ultimately deployed into your different environments.

For non-dockerized Java applications this is typically a JAR/WAR. For dockerized applications this is typically an image that contains the JAR/WAR.