Metalink Repositories: Stability Channels on January 23, 2019
Continuing on the topic of metalink repositories, one of the biggest advantages I have found is that I no longer need to worry about complicated rules for when products should be published and what downstream components might be affected. Instead, I can focus on defining what “alpha” vs “rc” vs “stable” mean, and then downstream components consume however it’s appropriate for them. That may sound sound trivial and obvious. However, I have found implementing those workflows in a product to be difficult before using metalink repositories (see Motivations for more details).


Metalink Repositories: Mirroring Third-Party Dependencies on December 30, 2018
When managing project dependencies which are outside of your control, it is often best practice to assume those artifacts may disappear (e.g. they may move, disappear, or become corrupt). For this reason, you may want to be mirroring your assets which, with metalink repositories, provides the functionality of: Multiple URLs can be configured for where to find an artifact. This allows for documenting where files were originally discovered, but also supports retrying download from mirrors if one location fails.

Metalink Repositories: Background and Motivation on December 28, 2018

A while ago I started standardizing on using metalinks to record information about blobs. In my original post about metalinks, I briefly touched on the idea of querying directories of metalinks, treating it as a lightweight database. This post starts a short series discussing what shortcomings motivated my interest in something like “metalink repositories” and how I have been building on the concept in several ways.


Documenting Blobs with Metalink Files on October 9, 2017

There are many blobs around the web, with different organizations and teams publishing artifacts through different channels and with varying security. Often a single project will have many dependencies from multiple different sources, and developers need to know specifics about where to download blobs and how to verify them. I started looking for a solution to help unify the way I was both consuming and sharing blobs across my own projects. Eventually I found my way to something called “metalink” files, and it has become a very useful method for managing blobs (and resources) in my projects.


Pruning Blobs from BOSH Releases on August 6, 2015
Over time, as blobs are continually added to BOSH releases, the files can start consuming lots of disk space. Blobs are frequently abandoned because newer versions replace them, or sometimes the original packages referencing them are removed. Unfortunately, freeing the disk space isn’t as simple as rm blobs/elasticsearch-1.5.2.tar.gz because BOSH keeps track of blobs in the config/blobs.yml file and uses symlinks to cached copies. To help keep a lean workspace, I remove references to blobs which are no longer needed in my release.