Jump to: navigation, search

Deployed to a repository


In general we use a non-standard approach to release builds. The standard approach to releasing python projects is to run something like 'sdist upload' and on java it would be using the java release plugin. We do not agree with those approaches to releasing software for a few reasons:

  1. It's doing too much, those things are doing build, test, deployments and even possibly tagging all in one. What we want is to simply copy a file to a repository.
  2. It's posing a security risk by downloading from multiple repsitories, we are concerned that something might get through that could re-route the downloads from an evil repository.
  3. Some release workflow make commits on deployment, that does not work well with the Gerrit review workflow because it would require a manual step to approval changes during the release.

So instead we use info from git to version the build then we use curl to publish the built artifacts to the appropriate repository.

CI Builds

When CI builds are created the artifacts are usually published to the tarballs file server. The build version will be something like $PROJECT_NAME-$TAG.$COMMITS_SINCE_TAG.$GIT_SHA

Release Builds

When a tag is created a jenkins job will do the following:

  1. Make a release build with version $PROJECT_NAME-$TAG
  2. Publish release build to tarballs
  3. Copy the released build from tarballs to an appropriate repository depending on the type of project that is built.

Note - only project core members have permission to create tags.


List of repositories we deploy to:

  1. Python projects are deployed to pypi
  2. General Java projects are deployed to maven central
  3. Jenkins plugins are deployed to jenkins repo