Most Developers “get” artifacts, but most can’t clearly articulate what an artifact is or how it works. When I first started learning Jenkins, the definitions I found online left me more confused than I started. 

The definition of an artifact from Jenkins themselves is:

“An artifact is an immutable file, generated during a Build or Pipeline run in Jenkins. These artifacts are then archived onto the Jenkins Controller for later use.”

Makes sense right? No? Well, let’s take a look at artifacts, what they are, how to build them, and where to store them.

So, what are artifacts, exactly?

In a nutshell, when you build software, you are taking your code and your dependencies and making a single executable file. In Windows-based projects, these will be an .exe file. These .exe files are called “artifacts.”

Artifacts are files, like .exe and .dll, that are “attached” to a build in the CI (build automation) system. They are associated with one single build and represent data created from running a build.

With an artifact, you can:

⭐ Use the same exact code that was compiled and passed testing

⭐ Download them as zip files and use them for deployment

Side note: All CI servers support artifacts 👍 

How to Create an Artifact

In Jenkins, an artifact is created in either Freestyle projects or Pipeline projects.

• In Freestyle, add the “Archive the artifacts” post-build step

• In Pipeline, use the archiveArtifacts step.

These archived files will now be accessible from the Jenkins webpage so that they can be downloaded later.

Jenkins as an Artifact Repository

Jenkins is great for a lot of things, we’ve written a lot about it. However, it was not designed to be an artifact repository. 

Jenkins keeps artifacts for a build only as long as the build log itself is kept. This means:

• Artifacts that you deployed to a server may be deleted
• There is no easy way to roll back if artifacts are deleted
• It’s unclear which Jenkins builds were deployed.

Not to mention, Jenkins artifacts are instantly associated with builds in projects (jobs). Therefore, renaming or recreating a project erases the related artifacts.

On a large team, it’s common to have multiple instances of Jenkins. This means, however, that there could be many or even too many places to search for artifacts. And if someone else renames a project, it’s possible you’ll be searching for lost artifacts forever…

The better option is to use a centralized artifact repository or packages.

3 Options for Storing Artifacts Outside of Jenkins

Like how it wasn’t designed to be an artifact repository, Jenkins also wasn’t designed as a storage tool for software assets. You can capture build artifacts as part of a Jenkins project, but these can quickly get lost in hundreds of other CI builds across hundreds of other projects.  

Storing release artifacts outside of Jenkins makes them much easier to find – and it saves on effort keeping Jenkins servers tidy.

Import artifacts to a dedicated CI tool

Using a dedicated Continuous Integration tool, like BuildMaster, means an artifact can be used throughout the CD process. A tool makes it easy to roll back to old versions whenever in case of production bugs.

Maven-based artifact repository

Maven is a useful tool, but its prime has passed since it was designed primarily for Java applications.

Maven projects are published to public “Maven Repositories;” web-based file shares. There are “index” files in these repositories that list what projects and versions are stored in the repository, as well as metadata files that describe what each project is.

It’s easier said than done; Maven can be confusing and difficult to use.

Publish universal packages

An alternative to Maven artifacts, universal packages are a single file that contains all your build artifacts plus a manifest file with the package’s name and version.

Install a package manager, like ProGet, on a server so you can see which package is installed where. And unlike using Maven-based artifacts, a package manager doesn’t require modification to your project or code.

Unlike artifacts, packages are “read-only,” Semantically Versioned, and have built-in metadata. The metadata tracks multiple fields like changes, authors, installs, and so on. It’s great for simplifying auditing and rollbacks.

Using ProGet as a Jenkins Artifact Repository

Ideally, you want to use a private Repository like ProGet to store your artifacts. A private repository means your proprietary artifacts, packages, and projects are accessible only to your team. 

ProGet is self-managed on-premise, just like Jenkins. You can download it for free, and ProGet works on both Windows and Linux – also just like Jenkins. ProGet also has configurable retention rules, so you can define what should and shouldn’t be kept to conserve space on your servers.

Creating an artifact repository for Jenkins is easy, and takes only a couple of minutes!

It’s important to keep your build artifacts, so a tool like ProGet that can handle both Maven packages and Universal Packages is ideal. Check out our guide on how to configure Jenkins and ProGet to publish and deploy universal packages.

Try downloading ProGet today and set up a private repository for free.

Creating a private repository for your Jenkins artifacts is just one way to make your Jenkins CI/CD more streamlined and efficient. For many more, why not check out free eBook “Level Up Your CI/CD with Jenkins”. Download your copy today!