Self-Serve Release Jobs
=======================
-Self-serve release jobs allow project committers to direct Jenkins to
-promote a jar file, container image or Python package from a staging
-area to a release area.
+Self-serve release jobs allow project committers to promote a jar
+file, container image, Python package or PackageCloud artifact from a
+staging area to a release area. A release yaml file controls the
+process, and Jenkins promotes the artifact when a project committer
+merges the release yaml file in Gerrit.
To use the self-release process, create a releases/ or .releases/
directory at the root of the project repository, add one release yaml
file to it, and submit a change set with that release yaml file. The
required contents of the release yaml file are different for each type
-of release, see the schemas and examples shown below. The version in
-the release yaml file must be a valid Semantic Versioning (SemVer)
-string, matching either the pattern "v#.#.#" or "#.#.#" where "#" is
-one or more digits. Upon merge of the change, Jenkins will sign the
-reference extrapolated by log_dir and promote the artifact.
+of release, see the schemas and examples shown below. The version
+string in the release yaml file should be a valid Semantic Versioning
+(SemVer) string, matching the pattern "#.#.#" where "#" is one or more
+digits. A version string matching the pattern "v#.#.#" is also
+accepted. Upon merge of the change, a Jenkins job promotes the
+artifact and pushes a gpg-signed tag to the repository.
.. note::
The release file regex is: (releases\/.*\.yaml|\.releases\/.*\.yaml).
In words, the directory name can be ".releases" or "releases"; the file
- name can be anything with suffix ".yaml".
+ name can be anything with suffix ".yaml". Some release jobs require
+ a specific prefix on the file, as described below.
The build node for all release jobs must be CentOS, which supports the
-sigul client for accessing a signing server. The build node for
-container release jobs must have Docker installed.
+sigul client for accessing a signing server to sign a tag. The build
+node for container release jobs must have Docker installed.
A Jenkins admin user can also trigger a release job via the "Build
with parameters" action, removing the need to create and merge a
:project: The name of the project.
:version: The semantic version string used for the artifact.
-The JSON schema for a maven release file appears below.
+:Optional Parameters:
-.. code-block:: none
+ :git_tag: The tag string to sign and push to the Git repository.
+ (default: the semantic version string)
- ---
- $schema: "http://json-schema.org/schema#"
- $id: "https://github.com/lfit/releng-global-jjb/blob/master/release-schema.yaml"
-
- required:
- - "distribution_type"
- - "log_dir"
- - "project"
- - "version"
-
- properties:
- distribution_type:
- type: "string"
- log_dir:
- type: "string"
- project:
- type: "string"
- version:
- type: "string"
+The JSON schema for a maven release file appears below.
+
+.. literalinclude:: ../../schema/release-schema.yaml
+ :language: yaml
Container Release Files
Docker images in the container-pull registry to promote to the
container-push registry.
-The JSON schema for a container release file appears below.
+:Optional Parameters:
-.. code-block:: none
+ :git_tag: The tag string to sign and push to the Git repository.
+ (default: the semantic version string)
- ---
- $schema: "http://json-schema.org/schema#"
- $id: "https://github.com/lfit/releng-global-jjb/blob/master/release-container-schema.yaml"
-
- required:
- - "containers"
- - "distribution_type"
- - "project"
- - "container_release_tag"
- - "ref"
-
- properties:
- containers:
- type: "array"
- properties:
- name:
- type: "string"
- version:
- type: "string"
- additionalProperties: false
- distribution_type:
- type: "string"
- project:
- type: "string"
- container_release_tag:
- type: "string"
- container_pull_registry"
- type: "string"
- container_push_registry"
- type: "string"
- ref:
- type: "string"
+The JSON schema for a container release file appears below.
+
+.. literalinclude:: ../../schema/release-container-schema.yaml
+ :language: yaml
PyPI Release Files
------------------
-An example of a PyPI release file appears below.
+An example of a PyPI release file appears below. Name of the release file must
+start with "pypi". For example releases/pypi-1.0.0-mypackage.yaml
.. code-block:: none
- $ cat releases/pypi-release.yaml
+ $ cat releases/pypi-1.0.0-mypackage.yaml
---
- distribution_type: pypi
pypi_project: mypackage
python_version: '3.4'
version: 1.0.0
+ log_dir: example-project-pypi-merge-master/17
The following parameters must appear in the PyPI release yaml file.
:Required Parameters:
- :distribution_type: Must be "pypi".
:log_dir: The suffix of the logs URL reported on completion by the
Jenkins merge job that created and pushed the distribution files
to the staging repository. For example, use value
:version: The semantic version string used for the package in the
setup.py file.
-The JSON schema for a PyPI release file appears below.
+:Optional Parameters:
-.. code-block:: none
+ :git_tag: The tag string to sign and push to the Git repository.
+ (default: the semantic version string)
- ---
- $schema: "http://json-schema.org/schema#"
- $id: "https://github.com/lfit/releng-global-jjb/blob/master/release-pypi-schema.yaml"
-
- required:
- - "distribution_type"
- - "log_dir"
- - "pypi_project"
- - "python_version"
- - "version"
-
- properties:
- distribution_type:
- type: "string"
- log_dir:
- type: "string"
- pypi_project:
- type: "string"
- python_version:
- type: "string"
- version:
- type: "string"
+The JSON schema for a PyPI release file appears below.
+
+.. literalinclude:: ../../schema/release-pypi-schema.yaml
+ :language: yaml
PackageCloud Release Files
--------------------------
-An example of a PackageCloud release file appears below.
+An example of a PackageCloud release file appears below. Name of release file
+must start with "packagecloud". For example releases/packagecloud-1.6-tree.yaml
.. code-block:: none
- $ cat releases/packagecloud-release.yaml
+ $ cat releases/packagecloud-1.6-tree.yaml
---
- distribution_type: packagecloud
package_name:
- - name: 'tree-1.6.0-10.el7.x86_64.rpm'
- - name: 'test.rpm'
+ - name: tree-1.6.0-10.el7.x86_64.rpm
+ - name: test.rpm
The following parameters must appear in the PackageCloud release yaml file.
These are not part of the Jenkins job definition to allow independent
:Required Parameters:
- :distribution_type: Must be "packagecloud".
:package_name: A list of names that specify the packages to promote.
- (Found via jenkins log when using gem to initally push package up eg.
+ (Found in jenkins console log when using gem to push package eg.
"Pushing /path/of/package/name-of-package.rpm... success!"
- OR using rest api call with generated token from packagecloud.io
+ OR using rest api call to query packagecloud.io repo
"curl https://packagecloud.io/api/v1/repos/test_user/test_repo/search?q=
| yq -r .[].filename"
+
The JSON schema for a PackageCloud release file appears below.
-.. code-block:: none
+.. literalinclude:: ../../schema/release-packagecloud-schema.yaml
+ :language: yaml
- ---
- $schema: "http://json-schema.org/schema#"
- $id: "https://github.com/lfit/releng-global-jjb/blob/master/packagecloud-release-schema"
-
- required:
- - "package_name"
- - "distribution_type"
-
- properties:
- package_name:
- type: "array"
- properties:
- name:
- type: "string"
- distribution_type:
- type: "string"
Jenkins Jobs
------------
file. Checks the format of the version string, downloads the package
artifacts from the PyPI staging repository, uploads the package
artifacts to the PyPI release repository, tags the git repository,
-signs the tag and pushes the tag to the git server. The release verify
+signs the tag and pushes the tag to the git server. The release merge
template accepts neither a branch nor a stream parameter.
:Template Names:
should be the repository pypy.org. (default: pypi)
:use-release-file: Whether to use the release file. (default: true)
+ :gerrit_trigger_file_paths: Override file paths filter which checks which
+ file modifications will trigger a build.
+ **default**::
+
+ - compare-type: REG_EXP
+ pattern: '(releases\/pypi.*\.yaml|\.releases\/pypi.*\.yaml)'
PyPI Release Verify
~~~~~~~~~~~~~~~~~~~
should be the repository pypy.org (default: pypi)
:use-release-file: Whether to use the release file. (default: true)
+ :gerrit_trigger_file_paths: Override file paths filter which checks which
+ file modifications will trigger a build.
+ **default**::
+
+ - compare-type: REG_EXP
+ pattern: '(releases\/pypi.*\.yaml|\.releases\/pypi.*\.yaml)'
PackageCloud Release Verify
~~~~~~~~~~~~~~~~~~~~~~~~~~~
This template supports PackageCloud release jobs.
-:Template Name: {project-name}-packagecloud-verify
+:Template Name: {project-name}-packagecloud-release-verify
:Comment Trigger: recheck|reverify
**default**::
- compare-type: REG_EXP
- pattern: '(releases\/.*\.yaml|\.releases\/.*\.yaml)'
+ pattern: '(releases\/packagecloud.*\.yaml|\.releases\/packagecloud.*\.yaml)'
PackageCloud Release Merge
This template supports PackageCloud release jobs.
-:template name: {project-name}-packagecloud-merge
+:template name: {project-name}-packagecloud-release-merge
:comment trigger: remerge
**default**::
- compare-type: reg_exp
- pattern: '(releases\/.*\.yaml|\.releases\/.*\.yaml)'
+ pattern: '(releases\/packagecloud.*\.yaml|\.releases\/packagecloud.*\.yaml)'
Setup for LFID, Nexus, Jenkins and Gerrit