artifactory-follower1.2.5 • Public • Published
Greenkeeper Enterprise Artifactory Follower
jFrog Artifactory is an alternative package registry that is prominent among Greenkeeper Enterprise users. Artifactory is mostly compatible with the main npm registry except for the
_changes feed. That’s why we introduced greenkeeper-postpublish, so Enterprise customers who can’t rely on @greenkeeper/changes can announce private package releases to Greenkeeper Enterprise.
How it works
Artifactory has no feed of packages pushed to it that is equivalent to the npm registry’s
_changes feed. This package emulates the functionality of
@greenkeeper/changes by using Artifactory’s REST API and Search Language AQL
The main logic loop is this:
- read timestamp of when the last search was run, or initialise with a current timestamp
- run a search for all packages since the timestamp from the previous step
- for all results, read the npm doc from the Artifactory API and store it in our
- for all results that we haven’t handled already (read: if they are in the
npmdatabase already), start a
The last search timestamp is kept in Redis and
registry-change jobs are run on our main
As a first itearation, this Artifactory follower uses a search for what Artifactory calls
item is a
npm parlance, e.g. a name plus a list of versions that gets increased with an
npm publish to the Artifactory registry.
Artifactory also has the notion of
releases which we don}t understand fully just yet and assume our customers don’t use at this point. Should this become relevant, the search can be easily adjusted to support that use-case.
Artifactory supports the idea of multiple registries and a virtual registry that combines multiple registries into one endpoint. It also allows one registry to be set up to be a local cache of the public registry. This module currently works by searching in the main virtual registry (see options below for how to customise its name), and by ignoring any items from the local cache, as we’re already getting updates from the public registry (see options below for how to disable this).
This is currently only tested with Artifactory 6.2, but should work with earlier versions just the same.
Note: This covers only end-user configuration. See the section “Deployment” for Greenkeeper Enterprise internal configuration.
The minimum configuration is a URL string
ARTIFACTORY_URL that is the URL to Artifactory.
ARTIFACTORY_PASSWORD can be supplied, if the authenticated requests are required.
More detailed configuration options:
REFRESH_INTERVAL: How often to search for new items. Defaults to 60s.
REGISTRY_NAME: Name of the npm resgistry within Artifactory. Defaults to
npm(the Artifactory default).
REMOTE_REGISTRY_NAME: Name of the remote registry within Artifactory (that is the public registry proxy). Defaults to
npm-remote-cache(the Artifactory default). Set to an empty string to disable filtering out locally cached items from the public registry, that way, Greenkeeper Enterprise only ever talks to Artifactory. Don’t disable this AND configure access to the public registry.
This is only available in Greenkeeper Enterprise, so no Greenkeeper SaaS considerations are taken into account.
Since this is an opt-in feature, a valid setup would include no need for this Artifactory follower. However, Replicated does not allow us to conditionally run containers based on user config.
To that end, the Docker container for this package is always installed and started, but in case no Artifactory configuration is found, it just idles. It does not exist, so we can make use of Docker’s
always restart policy in case the package is used and valid errors make the container stop.
The process is currently idling due to the fact that the
lib/redis.js module unconditionally opens a Redis client connection that sticks around forever and blocking a natureal process exit.
(c) 2018 Neighbourhoodie Software, All Rights Reserved
npm i artifactory-follower