Universal Package Tagging

A key factor in good package management is organization. How you organize and structure your repositories will help you to unlock the efficiencies and promises of modern DevOps processes.

There are, of course, a multitude of ways you can organize packages. You can group by version numbers, formats, architectures, filetype and more. At Cloudsmith we have supported this by extracting as much of this metadata as possible when you upload a package and making this metadata available for searching/filtering.

Sometimes, however, the metadata just wasn’t granular enough – or it didn’t provide quite the nomenclature that you may have wanted. You wanted more. And we are extremely pleased to say that we have now added a new feature that greatly expands upon this functionality. Presenting:

UNIVERSAL PACKAGE TAGGING

So, what is new about this? And why does it matter?

Well, in short, we now give you the ability to add ANY custom tags to ANY package or container, either during package upload or after the fact. And you can do this via the Cloudsmith CLI or the Cloudsmith API.

Let’s say for example that you were using Cloudsmith to distribute your packages to end-users, and you have “Free” and “Premium” editions of your package. Well now you can simply add “Free” and “Premium” tags to the respective packages, and then create Entitlement Tokens to give your users access to just the packages they should be allowed – without resorting to adding the edition into the filename or creating two separate repositories. You can manage it all from one central location. And of course, as Cloudsmith repositories are fully multi-tenant for package formats, you can apply these tags across all the package formats you use, all in one repository.

Or perhaps you would like to tag a package based on where it is deployed. You could tag a package as “rest-api”, or similar, to differentiate where in your production application the package is used.

Let’s look at an example

Let’s start off by listing the packages in our demo repo. The CLI command for this is:

cloudsmith list packages OWNER/REPOSITORY

So, we can see that we have a collection of RPM packages in this repo, with various different versions. Let’s check one of those packages to see if it has any custom tags attached. The CLI command for this is:

cloudsmith tags list OWNER/REPOSITORY/PACKAGE-IDENTIFIER

Example:

OK, this package does not have any custom tags. Let’s now add one, and the CLI command for adding a tag is:

cloudsmith tags add OWNER/REPOSITORY/PACKAGE-IDENTIFIER tag1, tag2, tag3

Example:

Great, we have now added a custom tag “free” to this package. We can repeat this for the other packages in the repository, varying the tags to suit our purpose. In addition, we can also specify that tags are “Immutable”, which means they can only be removed or altered by someone with Administrator permissions on the repository, or by the package owner. When we are finished adding tags, we can look at the repository on the Cloudsmith website:

You can see the new custom tags listed for each package alongside the tags that were automatically created from the metadata when the packages were processed after upload. We can now use these custom tags in any searching/filtering we need to do, or add them as a restriction on an Entitlement Tokens that we create for the repository:

The syntax for searching/filtering is the same syntax you use when creating a search-based restriction for an Entitlement Token, so it really is easy to create a set of access tokens that divide the repository up into subsets of packages.

Summary

Visibility of the attributes of your packages is important, it will help you not only structure your repositories but can also help you gain insight on what package is where or what package a group of customers can access. And it’s not just the basic attributes of a package that you need visibility on, it’s anything about a package that matters to your organization and workflows. With universal package tagging, you now have the ability to add your own searchable attributes to your packages, so you can define what is of importance.