Jump to: navigation, search

Difference between revisions of "Deployed to a repository"

(CI Build Deployments)
Line 1: Line 1:
  
This documents how we deploy our builds.
+
In general we use a non-standard approach to deploying builds.  The standard approach to deploying 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:
 +
# It's doing too much, what we want is to just copy a file to a repository.  Those are doing build, test, deployments and even possibly tagging all in one.
 +
# It's posing a security risk by downloading from multiple repsitories, we are concerned that something might get through that could re-route the builds to an evil repository.
 +
 
 +
So instead we simply use curl to deploy the builds to the appropriate repository.
  
 
== CI Build Deployments ==
 
== CI Build Deployments ==
Line 9: Line 13:
  
 
When tags are created the tagged build gets deployed to an appropriate repository depending on the type of project that is built.  Here is a list of some of the repositories:
 
When tags are created the tagged build gets deployed to an appropriate repository depending on the type of project that is built.  Here is a list of some of the repositories:
#. Python projects are deployed to [http://www.pypi.org pypi]
+
# Python projects are deployed to [http://www.pypi.org pypi]
#. General Java projects are deployed to [http://oss.sonatype.org maven central]     
+
# General Java projects are deployed to [http://oss.sonatype.org maven central]     
#. Jenkins plugins are deployed to [http://repo.jenkins-ci.org jenkins repo]
+
# Jenkins plugins are deployed to [http://repo.jenkins-ci.org jenkins repo]

Revision as of 18:51, 2 December 2013

In general we use a non-standard approach to deploying builds. The standard approach to deploying 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, what we want is to just copy a file to a repository. Those are doing build, test, deployments and even possibly tagging all in one.
  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 builds to an evil repository.

So instead we simply use curl to deploy the builds to the appropriate repository.

CI Build Deployments

When CI builds are created it usually gets deployed to the tarballs file server.

Release Deployments

When tags are created the tagged build gets deployed to an appropriate repository depending on the type of project that is built. Here is a list of some of the repositories:

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