Beat the binary repository developer (a.k.a. User Plugins)

From our experience with thousands of Artifactory users we know one thing for sure: we don’t know better. Every organization does its ALM differently: artifact approval flow, snapshot retention policies, build-to-release flow, governance, needed metadata and much, much more – they are all different. We definitely have some ideas on how the build and deploy process should look, but there are so many things that make your process unique. And that’s good. After all, you aren’t paid for working within the ideal deployment cycle, but for solving a business problem. At least I hope so.

Acknowledging the fact that we don’t know better complicates our lives as creators of a binary repository… and not only by hurting our ego. We want to give you the perfect tool for the job, but how can we do it without dictating to you what your job is? The solution is well known – extensions, a.k.a. add-ons, user plugins, you name it.

“OMG!”, you might say. “Code! Joy-joy! Finally, an excuse to hack around!” Or “OMG! Code! It’s your job to code those things into your product, not mine!” Look, either way, we don’t have much choice, do we? When it comes to customizations, you have to tell Artifactory what you want it to do. We can only try to do our best to make it simple for you. So, we developed a simple DSL.

In this post, I’ll show you how easy it is to customize Artifactory with user plugins. Here’s the story: you want to prevent downloading of deprecated artifacts. The deprecation information is attached as custom metadata to the artifacts by some quality-assurance mechanism.

Let’s say, for example, the artifacts to be banned from download are marked with property “deprecated=true”. Artifactory allows you react (with code) to various events in the system. You can find the list of available callbacks in the User Plugins documentation. So, we are going to write Download plugin and the callback we are looking for is the altResponse. In this callback, we can provide an alternative response instead of the one Artifactory was asked for. Here’s the code:

 1 download {
2     altResponse { request, responseRepoPath ->
 3         defdeprecated = repositories.getProperties(responseRepoPath)
 4         if(deprecated && deprecated.toBoolean()) {
5             status= 403
 6             message= 'This artifact was deprecated, please use some 
 7             log.warn "Request was made for deprecated artifact:
 8         }
 9     }
10 lines of code. That’s all. Let’s examine them:
  • It’s Groovy! If you are into it, good for you, enjoy! If you aren’t, don’t worry. It’s amost like Java, so you’ll read it without problems and will be productive from day 0.
  • It’s super-simple.

Here we go, line by line:

  1. Declares that it’s a Download plugin.
  2. Defines the callback type we want (altResponse). When we are implementing alternative response Artifactory provides us with 2 objects:
    • The request, instance of org.artifactory.request.Request. It encapsulates the information about incoming request, such as client details and the information requested
    • And responseRepoPath, instance of org.artifactory.repo.RepoPath. It encapsulates the information about the artifact to be returned.
  3. We want to get the first value of ‘deprecated’ property, if defined on the artifact represented by responseRepoPath.
  4. If the value exists and it is ‘true’, 1 or ‘y’ (as declared by toBoolean())
  5. set return code to 403 (Forbidden) and
  6. set the correct error message and
  7. optionally – issue warning to the Artifactory log.
Well, that’s all. Now, when you saw that the dragon of user plugins isn’t so scary, just think about the unique ways you could automate your delivery cycle, apply regulations and checks, or provide your corporate users with better Artifactory experience. Here are some samples and community contributed plugins to ignite your imagination.
Enjoy your build!