Difference between revisions of "Deployed to a repository"
| Line 1: | Line 1: | ||
| − | + | = Overview = | |
| − | In general we use a non-standard approach to | + | 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: |
# 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. | # 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. | ||
| − | # It's posing a security risk by downloading from multiple repsitories, we are concerned that something might get through that could re-route the | + | # 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. |
| + | # 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 | + | 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 | + | == CI Builds == |
| + | When CI builds are created the artifacts are usually published to the [http://tarballs.openstack.org tarballs] file server. The build version will be something like $PROJECT_NAME-$TAG.$COMMITS_SINCE_TAG.$GIT_SHA | ||
| − | When | + | == Release Builds == |
| + | When a tag* is created a jenkins job will do the following: | ||
| + | # Make a release build with version $PROJECT_NAME-$TAG | ||
| + | # Publish release build to [http://tarballs.openstack.org tarballs] | ||
| + | # 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. | |
| − | + | === Repositories === | |
| + | List of repositories we deploy to: | ||
# 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 05:35, 12 December 2013
Overview
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:
- 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.
- 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.
- 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:
- Make a release build with version $PROJECT_NAME-$TAG
- Publish release build to tarballs
- 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.
Repositories
List of repositories we deploy to:
- Python projects are deployed to pypi
- General Java projects are deployed to maven central
- Jenkins plugins are deployed to jenkins repo
