Are you sharing code between your different projects? Depfu now supports all package registries you might use for your own private shared libraries.
For Ruby we’ve added support for all external sources. That could be self-hosted gem servers, like Geminabox and Gemstash or SaaS registries like Gemfury and packagecloud. Also public 3rd party sources like Rails Assets and private sources like Sidekiq Pro/Enterprise are supported now.
Let’s have a look at how that works in detail:
Depfu auto-detects any registries you are using that are not the official rubygems.org or npmjs.org. The way this works depends on the language:
In Ruby the additional sources are part of your Gemfile, usually like this:
source 'https://rubygems.org' gem 'rake' # all my private gems: source 'https://gem.fury.io/depfu/' do gem 'myprivate_gem', '~> 3.7' end
Here we would detect that you’re using another gem source and check if we can access it or if it needs authentication.
.npmrc to do the detection. In this file you can tell npm how to authenticate and which package scopes should live in what registry:
From this example we would know that the scoped @flowbyte packages live in the “external-registry” and there might be additional private packages on npmjs.org, which Depfu will find later.
In most cases these external registries need some kind of authentication, since you want to use them for sharing private code as opposed to code that could be open-source.
That means that we rely on you to also give us access to these external sources. This is the same as giving your CI-system access in order to install the packages and run your tests. Most external sources have a way of only giving read access, which is all we need for Depfu.
After we detect an external source, we ask you to tell us how to authenticate. That could be username:password or usually some kind of token. You can enter this information in the settings for your organization:
In case of Bundler we actually need the auth information to continue sending you updates at all, even for public gems. Bundler constructs a full dependency tree to run any update and your private gems are part of that as well. Apart from monkey-patching Bundler heavily, which we obviously want to avoid, there is no way for us to ignore your private gems while sending you updates for public gems.
Polling and Updates
After we have access to an external source, we start polling it regularly and will send you updates via pull requests the exact same way as for your public dependencies.
We intentionally have some delay in the system, so don’t be surprised if the pull requests don’t come in right after you released a new version of your private library.
Push vs Pull
Apart from helping you to keep all your dependencies up-to-date, we think moving your own private libraries from a pull to a push method is a big improvement. If you ever had to do the checkout/update/push-dance to update a shared library in a lot of projects at the same time, you’ll realize how much nicer the push model is.