Lee Skillen from Cloudsmith on streamlined software packaging, building startups, and on-premise

Lee Skillen, Founder and CTO at Cloudsmith, joins SemaphoreCI to discuss how Cloudsmith solves the complex issue of streamlined software packaging.

We also discuss the ups and downs of being an entrepreneur and starting one's own business.

This episode is also available as a podcast at 

https://semaphoreci.com/blog/lee-skillen-from-cloudsmith-on-streamlined-software-packaging

What is Rust? What is Cargo? What are Crates?

Rust lang, or Rust, is a systems programming language, designed at Mozilla research, and intended to be a safer alternative to existing systems programming languages like C and C++, but still just as fast. Rust was originally started as a personal side-project by Mozilla engineer Graydon Hoare, but the company quickly and rightfully recognised its promise and began sponsorship of the project in 2009.

Rust quickly became a critical part of Mozilla's efforts to improve the performance and reliability of their browser technology as part of the Servo project. Since then, Rust has only grown in popularity and appeal, year on year, and for the last four years has achieved the coveted top spot for "most loved programming language" on 

Whilst Rust is maybe best known as a low-level systems language, the same properties that make it appealing for working close to the metal also make it appealing for many other use cases. Rust's memory-safety, ownership semantics, performance, and comprehensive type system (among others) combine to make Rust a very compelling choice in many fields of engineering.

Whether you're writing a device driver for an embedded System-on-Chip (SoC), an operating system, a layout engine for a web browser, a web application, a package management service (heh), or a library for use in the WebAssembly ecosystem, Rust probably has you covered.

Early on, the Rust community realised that for a modern programming language to be successful, it needs modern tooling to accompany it. To this end, various teams in the Rust community have concentrated on tooling, such that Rust is now widely regarded as having best-in-class tools in areas like build and package management; which is something that we (Cloudsmith) recognise, respect and adore.

Rust therefore ships with its own package manager called 

. Cargo is an all-in-one frontend for building, packaging and configuring your Rust projects. It can build and run your code (providing a developer-friendly interface to 

) and manages resolving and fetching any required dependencies (also known as "crates" in the Rust world).

Cargo can install dependencies from a remote registry into your local project for building, using a command like 

. Until April of 2019 the only choice you really had was the official, public registry at 

. Crates.io is maintained by the Rust team and is the default public registry for the Rust ecosystem. With the 

, Cargo now officially supports the use of registries other than crates.io, making it possible to run an alternative registry for the hosting of private or internal crates.

There are several equally fantastic reasons for running/using your own registry:

To develop Cargo packages internally and share them privately to other teams.

To distribute and deploy your own Cargo packages in a pipeline at your org.

To distribute Cargo packages as vendored software (i.e. maybe commercially).

To make modifications to public Cargo packages, without republishing publicly.

To mirror public Cargo packages, to isolate from uncontrolled registry events.

To capture the exact state of your dependencies at a particular version/release.

To control (whitelist/blacklist) the exact Cargo packages allowed for your org.

To keep track of the exact versions/releases of Cargo packages you have/use.

As such, if you're interested in the possibilities that hosting your own private or internal crates brings, then this is incredibly good news for you: Cloudsmith are proud to provide the World's first commercially available public and 

, with ultra-fast and secure delivery of your Rust packages, alongside all of the usual Enterprise-grade features that we provide.

https://doc.rust-lang.org/book/index.html

https://doc.rust-lang.org/cargo/index.html

Setting up a private Cargo registry at Cloudsmith

Getting started with Cloudsmith and Cargo couldn't be simpler. First, you'll need a 

 and a repository to which you can upload crates. Secondly, you'll need to ensure you're running at least version 1.34 (or later) of Rust.

, the Rust toolchain installer. Rust is available on most commonly used development platforms.

You can check your currently installed Rust and Cargo versions like so:

If you see something like the above, you're ready to go!

Publishing your Cargo crates to Cloudsmith

For the purposes of this demonstration, we'll use the minimal crate created by 

. You can initialise your new Cargo crate like so:

If you take a look inside the new crate you'll see a few files:

 contains a simple "Hello World" program, and 

 contains all configuration and setup data for your crate. For our purposes we can leave both files as-is.

 to build our crate and prepare it for upload to Cloudsmith:

 command as we haven't committed the new crate to git. Under normal circumstances you'll just call 

Cargo, by default, spits out your packaged crate under the 

Once built you can push the crate to Cloudsmith using the 

. We don't yet support pushing crates with 

, but we'll be adding support in a future release (if you want it, please let us know). For now, use the CLI.

First, ensure you've installed the Cloudsmith CLI and configured authentication:

Then, use the CLI to push the crate, which operates like 

Your repository should now contain the uploaded crates. An example of which is our official Cloudsmith examples repository (this is where we upload 

Once pushed, your crate is ready for installation with Cargo.

Installing your Cargo crates from Cloudsmith

First, we need to tell Cargo how to access the registry. To do so you need to add the following entry in your 

 with an entitlement token, which is a type of read-only authentication token that we support):

 then you should be able to run the installed program:

It really is that simple, and now you've sourced a crate privately from your very own private Cargo registry on Cloudsmith. Well done!

Rust is an exciting new programming language, with many interesting properties that make it perfect for use in a wide range of scenarios. Cargo provides a robust suite of tools for installing, configuring and managing dependencies for your Rust projects.

Cloudsmith provides fully featured Cargo registries on all plans, flexible enough for use whether you’re hosting public crates for a public or open source project, or private crates for your company’s internal needs. We're extremely proud to be able to support the Rust ecosystem with this first (non-official) implementation of public and private Cargo registries.

You can find further, context-specific information, including detailed setup and integration instructions inside each Cloudsmith repository. You can see an example of this documentation in our 

World's First Private Cargo Registry w/ Cloudsmith + Rust

 hosting, with ultra-fast and secure delivery of your Helm charts; for the ultimate in integration with the Kubernetes (k8s) ecosystem.

How to host your own Helm repository using Cloudsmith

Originally built by Deis (later acquired by Microsoft), Helm is a package manager for Kubernetes that allows development and operations teams to easily manage and deploy these increasingly complex cloud native applications to their Kubernetes clusters. Helm allows you to manage applications on your Kubernetes cluster in much the same way as you’d manage applications on your Linux server with apt or yum.

 (otherwise known as K8s) is an open source system to deploy, scale, and manage containerized applications. Kubernetes has quickly become one of the most popular container orchestration platforms used by development and operations teams all over the world. It was open-sourced by Google in 2014, built based on years of learning deploying containers at scale inside the search giant.

Despite Kubernetes’ rapid rise to popularity, deploying and managing applications can be a complex and daunting task, often requiring the operator to write and configure multiple inter-dependent configuration files for various parts of the systems being deployed. As our applications become more complex, more distributed, the difficulty of managing them grows even further.

A Helm chart is a collection of Kubernetes YAML template files organized into one single directory. Helm packages are also known as “Helm Charts” and are stored in a “Chart Repository”. By default, Helm comes bundled with the “stable” chart repository, hosted for free by Google. Most public charts are hosted here, mostly provided by vendors packaging their own software for use by others.

Through Helm charts, Helm is used to manage Kubernetes applications. It works by packaging up a set of YAML definitions along with the necessary configuration to quickly stand up all components of an application in a repeatable way. A single chart can be as simple or complex as necessary, deploying anything from a single container to a full distributed application. Helm combines these application definitions with user-provided configuration to allow simple overriding of configuration where needed, allowing users to concentrate on shipping software and not on the nitty-gritty of configuring every application they need to run.

The main requirement for using Helm is a working Kubernetes installation. Setup of Kubernetes is outside the scope of this post, but you can get started locally with the installation of 

, you can initialise Helm on your cluster:

, Helm’s server-side component, responsible for interacting with the Kubernetes API and managing state.

You can then run other Helm commands as needed. To view all available charts you can use the following command:

You should see a full listing of the built-in “stable” repository which contains all supported public charts. You can install any of the charts from the 

This instructs Tiller to pull the packaged chart from the stable repository, render all the templates contained within, and apply those to the running cluster. You can inspect the status of the application with regular Kubernetes CLI tooling:

Or check the status of the chart installation itself using the 

If using only public Helm charts to install third-party applications, then the above instructions are enough to get started in most cases. But if you want to install software for which there are no public Helm charts, whether your own or third-party, you can create your own chart and host it using Cloudsmith.

If you’re creating your own chart, you can use one of Helm’s starter templates to quickly scaffold out the directory for you:

 folder containing all the files and folders necessary to build your chart. You can adjust the templates as needed for your application, 

 is a really useful resource when building your own chart.

Once you’ve finished adjusting your templates, you can create a Chart package with the CLI:

Once built you can push the chart to Cloudsmith. First, ensure you’ve installed the Cloudsmith CLI and configured authentication:

Then, use the Cloudsmith CLI to push the package:

Once pushed, you can configure Helm to install packages from your Cloudsmith repository:

And then install your application to Kubernetes:

There you have it! We have also produced a handy video guide on getting started with Helm using Cloudsmith, which you can follow below:

Getting Started with Helm and Cloudsmith

A short video demo of how to get started with Helm and Cloudsmith, including pushing a Helm Chart to private Cloudsmith repository and then pulling and installing the Chart on a Kubernetes Cluster.

Helm is a powerful tool to help manage the ever-growing complexity of deploying and running cloud native applications on Kubernetes. Like other package managers Helm provides a robust suite of tools for installing, configuring and managing applications on its target platform, Kubernetes.

Cloudsmith provides fully featured Helm repositories on all plans, flexible enough for use whether you’re hosting public charts for an open source project, or private charts for your company’s internal applications.

You can find further, context-specific information, including detailed Helm setup and integration instructions inside each Cloudsmith repository. You can also see an example of 

If you're intrigued to learn more about specific package formats, delve into our series below:

An Introduction to Helm

Can you believe it's summer-time already? It's hard for us to tell from the cave that we're coding in day and night, but the office thermostat indicates that it is probably sunny way up there, above the ground. It does mark a fantastic occasion to bring you news of some juicy pieces of new functionality to help get you automated, now with even more secure delivery of your software.

We're extremely pleased to announce one of our features that we believe brings us full circle in terms of achieving data portability in and out of the service: Webhooks. This isn't a fancy term for a new Spider-Man gadget. Where the RESTful API (and CLI) allow you to easily get data into the system, the webhooks allows us to push data about events to you. Now you can do clever things like react to a package being promoted to a production repository, in order to drive your pipelines to start a deployment.

So yes, the circle is now complete for data portability. Which is great, of course, but we know what you're thinking: Hurry up and get NPM / Docker / NuGet / Alpine / Bower completed (delete as appropriate), and you'd be right. We're working hard on it indeed, in between working on raising funds to speed things up, and we'll hopefully have even more exciting announcements next time.

TL;DR: You can now have Cloudsmith inform you, your cats and your servers about events that happen, such as new packages being synchronised. Drive your pipelines or ChatOps with it!

 The "Webhooks" sub-menu of each repository.

Webhooks - What are they good for? Either for driving automation by pushing data to your pipelines, or by integrating with your chat tools to provide slick ChatOps. Our webhooks support events that occur in a repository, such as when packages have been uploaded, are synchronising, have synchronised or have failed. We plan to add more events in the future, and to have them creatable at the the namespace (user/org) level, or site-wide on Enterprise edition.

For pipeline automation, you might utilise webhooks by setting up one to tell a CI/CD tool such as Jenkins, or perhaps Spinnaker (if you're being fancy) that it is time to deploy when a synchronised package is moved to your production repository. In this way, you can control the flow from development to production by limiting who (or what) has the authority to move packages to the production repository, and thus, to deploy publicly.

For ChatOps, you can utilise webhooks to send a message to a chat tool such as Slack when each type of event occurs. You'll format this in such a way so as to present critical information to your team, such as what the package is, where it is located, who uploaded it, and how to access it, etc. If you're really fancy, you'll have a Slack integration that lets users interact with Cloudsmith via slash commands, for super slick bi-directional DevOps goodness.

Creating a webhook is simple and only requires an endpoint to send it to. If you're looking to create a Slack integration, we highly recommend using the 

 is a mini templating language that you'll use to craft the output of the webhook. More help is available on-site, but if you're stuck, just yell. In the near-future we'll offer more concrete documentation, and beyond that we'll add more tightly integrated plugins for things like Slack that do the hard work for you.

TL;DR: We've added support for Composer packages (in the form of .phar, .tgz, .zip, etc.), so that you can have your PHP packaging with all the usual Cloudsmith goodness.

 The "Upload Packages" sub-menu of each repository.

As defined by Wikipedia: "Composer is an application-level package manager for the PHP programming language that provides a standard format for managing dependencies of PHP software and required libraries". Cloudsmith now provides PHP as a first-class package repository type with support for most of the metadata that a typical composer.json file exports. Get started by uploading a Composer-compatible .phar package built with phar-composer or similar.

If you're using the UI to upload packages then Composer support is immediately available (as per image above). If you're uploading via the CLI you'll need to download and install the latest (0.6.1) version of the cloudsmith-cli application. Assuming you've followed the usual instructions for installation, you can do this with a simple invocation of pip to update your CLI:

TL;DR: You can now signup and login using third party social authentication credentials from providers such as Amazon, GitHub, GitLab, Google and Microsoft.

This one is probably the most obvious because it's hard to miss, but we've added the capability to login via social providers (as you can see below) such as Amazon, GitHub, GitLab, Google and Microsoft. In the future we'll add additional support for more complicated and Enterprise-level authentication integrations, such as being able to use a third party AD service for orgs. For now though, please enjoy the convenience of jumping services.

Since you've already got an account, you'll need to login first and then manage your social accounts in your user settings. You will then be able to connect each of the supported social providers to your account so that you can login with them next time. In the future we'll offer slicker association from login by asking you to re-enter your password if you try to login with a social account but you already have a (previously unconnected) Cloudsmith account.

TL;DR: You can now use two-factor authentication to protect your logins, your Organisations, and your packages with an additional level of security.

https://cloudsmith.io/user/settings/security/

Two times the security. Twice as secure. Right? Well, that only matters if the base level of security is strong to begin with. At Cloudsmith security is one of our most paramount concerns, and we utilise our collective years across different disciplines such as financial technology and Internet startups to apply this to package management. You can see this in the architectural DNA of the service, such as how we process packages away from the front-end, through to utilisation of front-end security techniques, such as the use of Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), etc.

We now have support for two-factor authentication via a TOTP (Time-based One-time Password Algorithm) device, such as Google Authenticator, LastPass Authenticator, etc. Once you've completed enrolment (i.e. registration of your device with us), you will be challenged to authenticate via the device after social or password-based login. You do this by entering in a 6-digit pin that your device presents. If you forget your 6-digit pin, we also offer a recovery service using disposable tokens.

If you're the owner of an Organisation (as defined by Cloudsmith) you can also force enforce enrolment of two-factor for everyone in the Org. A flag that denotes 2fa within the members list will tell you if the member has two-factor enabled or not. If you enforce enrolment and a User hasn't yet enroled, they will not be able to access any of the pages for the Organisation (e.g. they can't view or manipulate packages). If you are security conscious, please consider enabling this.

TL;DR: You can now add and manage multiple email addresses per User account, in addition to managing your subscriptions to the kind of emails we love to send you to keep you in the loop.

https://cloudsmith.io/user/settings/emails/

It's often the case that one ends up juggling multiple email accounts and using them at the same time to access different services. This is often the case if you belong to multiple organisations and each provides you with an email address that is specific to it. To help manage and facilitate this, you can now add multiple email addresses to your Cloudsmith User Account. Once an email is verified you'll be able to login with it. You can also specify your primary email address, which is the one that we'll email you with when contacting you.

In addition to that, we're proud to say that we're fully compliant with the latest privacy laws in the EU (the GDPR, which you've likely heard about more often than you'd like to). As such, you can now manage your email communication preferences and choose whether you want to opt-in or opt-out for emails. You're reading the newsletter right now, so if you opt-out of that we'll not send you it anymore; but then you'll not know about new features like this. :-)

TL;DR: You can now limit downloads to specific packages or download paths, by maximum number of downloads or clients, or by start or expiry dates. Oh, and support for user-based metadata.

 The "Entitlements" sub-menu of private repositories.

We have built Cloudsmith around servicing a trifecta of business use-cases, sometimes called the "3 'D's of Package Management": Dependencies for development, Deployment for operations, and Distribution for Vendors. The third use-case, distribution for Vendors, is all about empowering Users to securely distribute their software to the world at high-speed. It doesn't matter whether the software is free, open-source, or proprietary and paid.

If you're selling software and distributing it via Cloudsmith, you'll likely have a license that is associated per Customer and which dictates their terms of usage. Associating the license with an entitlement allows you to control and track downloads of the software specifically for that license. For example, you could only allow the Customer to download specific packages, between August 1st 2018 and August 1st 2019, up to a maximum of 10 downloads from one location (i.e. a single client).

Each entitlement can have different restrictions, and you can use the freeform (JSON-based) metadata to add your own information into the entitlement. Support is already available via the UI and via the API, but we'll be adding full support for the enhanced functionality to the next release of the CLI.

TL;DR: You can now search for packages using full boolean queries (with AND/OR/NOT support), along with additional attributes such as distribution, format, status, etc.

 The search bar on top of the packages list in repositories.

You may or may not recall that in a previous newsletter we said that we'd be gradually rolling out more FOPS support across the site - In case you've forgotten or have never heard of it before, FOPS is our endearing term for 

earch support across the website. This is something that we'd like to make universal across the UI, the API and the CLI, and we're gradually rolling out support where we can. We're still not pleased with our current FOPS level, so we're continuing to add this in-between other feature releases.

This month's flavour is the addition of Full Boolean Search to the packages search functionality. Previously we only supported an implicit AND query (i.e. all terms must be present). Now you can take advantage of the full boolean query parser to build complex queries with any combination of AND, OR and NOT. You can use parentheses to group terms if required. As part of this functionality, we have also added support for other search terms, such as distributions (e.g. 'el' for enterprise linux), format (e.g. 'deb' for debian packages), status (e.g. 'in_progress' for packages in progress). Help is available by hovering on the question mark.

Support is immediately available via the UI, API and the CLI. You might be excited to know that in the near-future we'll be rewriting the CLI actions that target packages to use the search functionality instead of having to use things like auto-generated slugs (which we appreciate is painful and hard to predict).

In addition to the above, the following changes have made it in:

You can now set email communication preferences.

Each repository page now has additional intro/help text.

The Entitlements list now reflects additional info for restrictions.

Downloads and clients are now tracked per entitlement token.

Access logs related to packages now link back to package.

Many fixes and enhancements across the user interface.

You can see the full log of changes for the latest releases at:

We're full steam ahead on improving the service, and we're likely to have a bumper pack month or two coming up. Expect big changes as we on-board more developers.

With that said, here are some little slices of awesome from the 

NPM Packages: A fully-fledged NPM repository (soon).

Better Documentation: A manual on how to use this beast.

Upstream Proxying: Utilising us as a package proxy cache.

Package Redeployment: Overwrite (redeploy) your packages.

CLI Upgrades: Adding new entitlements/webhooks support.

Landing Redesign: Better information on what/why we do this.

Multiple Actions: UI for affecting multiple packages at once.

Docker Packages: A fully-fledged Docker repository.

If you feel particularly strongly about any of those, or if you've got suggestions of your own, don't forget to vote and submit ideas for the 

. You'll need a Trello account to add your thumbs up, but it's free and easy to signup. No excuses!

If you've run out of your trial period, but want to try some of the latest premium features, no problem. Reply to let us know and we'd be delighted to offer you an extension. In fact, we offer this to any user who has missed their chance to trial the service properly, for whatever reason. Just ask!

You want to see us succeed, right? Of course you do! To do that we have a humble favour to ask - As a startup who is currently in the throes of an investment round, we can do with all the help that we can get to make things more awesome. The more traction that we can build, the stronger and better the service that we'll be able to build for you. If you can help us by promoting us through word-of-mouth, by writing an article or featuring us, or simply by providing a qualified link back to us, we'd be eternally grateful.

As you might have experienced, we do our best to support all of our users in any way that we can. If that means helping you write some code to automate or integrate, we're happy to do so. Some of these things would be hard to scale, but transparency and open/honest friendliness is something that we build into our company ideals, and is something we'd like to continue doing as we grow larger. Getting you automated in the easiest and most secure possible way is the reason that we built Cloudsmith.

Let's do this together - If you help, please let us know. :-)

Other than that, as always we hope that you enjoy the latest functionality, and if you've got any questions about any of the above, or need help from integration to use-case guidance, please don't hesitate to reply or contact us on the usual channels.

The Circle Is Now Complete

 Cloudsmith released Phase II of our API+CLI which gives users greater control over package handling including search, entitlements and package actions. We're very excited by the additional possibilities of automation and integration that these introduce. If we're helping you automate, we're doing our job right.

Balancing the quest for automating everything with a sublime user-experience is never an easy thing, but we've found that if there's one thing that users love, it is FOPS - an affectionate term that we use for 

 functionality, and the releases this month are delivering it in spades.

Note: To take advantage of the API/CLI features in this newsletter you'll need to upgrade your CLI to the latest version (0.5.5 or above), which you can easily do via pip:

You can now list, create, update, delete, refresh and sync entitlements and their tokens via the API and the CLI.

A hugely requested feature is the ability to manage entitlements for a repository via the API and the CLI, and the following is now possible to do so:

List entitlements in a repository (tokens can be hidden/shown).

Create new entitlements for a repository.

Delete existing entitlements from a repository.

Refresh existing entitlements in a repository (update token).

Update existing entitlements in a repository.

Sync all entitlements from source to destination repository.

This opens up new possibilities such as integrating automation of access controls or licensing into your own development or sales pipelines. For example, if you're selling software or libraries that you distribute via Cloudsmith, you could programmatically create an entitlement that you associate with a customer. Now the customer has direct access to your software using the entitlement. When the customer stops paying, remove the entitlement and they will no longer have access to new updates for it.

Here's a quick example of what this looks like in the CLI:

As you can see we deleted an old entitlement from the repository, then created a new one for this newsletter (you can provide a specific token or let the service generate one for you). Tokens are not displayed by default, but you can use the --show-tokens parameter to show them.

To see the full list of entitlements commands, run the following:

You can now copy, move (and resync) packages via the API and the CLI.

Another popular feature is the ability to copy or move packages between repositories, usually for the concept of promoting immutable versions of packages between separate build, test, staging and production pipelines - It means that the package that was verified in build is eventually the exact same one as in production when it gets promoted to there. It is now possible to automate copying and moving of packages using the CLI.

Let's see an example of moving a package in action:

As you can see, the sl package was moved (or "promoted") from the source repository to the dest repository. Copying packages works exactly the same, except it duplicates the package rather than moving it from the source to the destination.

In addition to moving and copying packages, you can also resync packages via the CLI as well, which the CLI will now also utilise to retry packages that have failed (for whatever reason) upto a configurable amount of attempts.

To see the full list of help for actions, run the following commands:

You can narrow results when listing packages using the search queries against package attributes (such as filenames).

A feature that we've been asked for time and time again is the ability search for specific packages in a repository. This is especially important as your repository grows in size and complexity beyond a few pages of results. Now you're able to query packages based on attributes such as name, version, filename, distribution, architecture, and more to come soon.

Let's see an example of searching packages in action:

As you can see the results have been narrowed from the full list down to packages with libxml2 in their filename, and then again to the specific 2.0.0 version. Who knew searching could be so exciting? It is when you realise what you can do with it, but let's see that in action in the next section.

In the future we'll be expanding the CLI functionality so that you can target packages using attributes instead of the slightly opaque slug that we currently use, which we realise isn't that convenient for delightful users such as yourself. So for example, instead of:

Perhaps you'll be using something like (tenative) this instead:

You can now get machiner-readable JSON output for list-based commands (and more later).

Having the API and the CLI opens up amazing possibilities for automation, because you can programmatically query and effect actions on the service. What isn't great though is having to parse arbitrary output formats (our CLI tables) designed by demented but visionary developers (that's us).

As such, we've implemented JSON-based outputting for some of the critical CLI commands. Essentially any command that outputs a table can now be told to output JSON instead. This provides the full data that is received via the API, and means you can write more powerful integrations using that data rather than the limited subset that gets output when pretty printing tables.

Let's see an example of that in action, and what you can do with it:

As you can see there is far more information that is returned via the JSON output format than the standard pretty table-based output. If you're not a machine but you'd still like JSON output, you can also use the 

 output format instead. One exciting use of this is the query for specific packages you need, and then use their attributes to perform actions, such as downloading the package as we've done in this example. More automation!

You can now search and filter packages in the UI using the same syntax as the CLI.

We wouldn't want the delightful user-experience of being able to search be constrained to just the CLI, so in our quest for FOPS you can now also search and filter packages on the UI too. The search offers the same syntax as the CLI-based search, and filtering allows you to group packages based on type and status, as you can see in the screenshots below:

We now have automatic grouping of packages by name.

As with the necessity for search, being able to quickly find the packages that you need within larger and more complex repositories is difficult. As a package management provider we are (of course) primarily focused on packages, and most packages have a name and version. So to help with that management we've introduced a package groups view that automatically groups packages by their name together as a group of versions (if it has one, if not it'll be in the UNGROUPED "group").

As you can see the grouping makes it much easier to find packages that are similar to each other. You're also offered a summary view of that group which includes the amount of packages there are (at a specific state), the name of the group, the top (highest) version of the packages, the last (uploaded) version of the packages, the number of downloads across group and the total size of group.

You can now control who can execute copy, delete, move and resync actions for packages at a repository-level.

Permissions (the ability to do something) and privileges (who has the ability get permission to do something) is a critical piece of managing your infrastructure and software. Being able to provide a fast-and-loose repository is great for development, but not so much when you need a locked down repository for production.

So in addition to our standard privileges model, we now offer granular permissions to control who can copy, delete, move and resync packages in a repository. An example scenario of where this is useful is allowing uploads to a production repository, but no deletes (or moves). Let's see an example of the configuration:

Note: We're working on the aesthetics to make this smaller and easier to read (and use) in an upcoming release.

Little slices of awesome from the roadmap (no particular order):

Webhooks / Notifications: Power your pipelines!

Lee Skillen, Cloudsmith CTO, on streamlined software packaging, building startups, and on-premise

More articles

World's First Private Cargo Registry w/ Cloudsmith + Rust

An Introduction to Helm

The Circle Is Now Complete

Lights, Entitlements, Actions!

Automation: As Simple as A, B, CLI.