X-Git-Url: https://gerrit.linuxfoundation.org/infra/gitweb?a=blobdiff_plain;f=docs%2Fjjb%2Flf-release-jobs.rst;h=9d5b1886067393372e95fb0c81b6c8246e377199;hb=refs%2Fchanges%2F50%2F61650%2F2;hp=0a9cc09ec9fbbf9a3daa481059f9e5580e016b16;hpb=5c49acecbc25ed26a243ac39885895ee3955fab9;p=releng%2Fglobal-jjb.git diff --git a/docs/jjb/lf-release-jobs.rst b/docs/jjb/lf-release-jobs.rst index 0a9cc09e..9d5b1886 100644 --- a/docs/jjb/lf-release-jobs.rst +++ b/docs/jjb/lf-release-jobs.rst @@ -4,17 +4,27 @@ Self-Serve Release Jobs ####################### -Self-serve release jobs allow a project team to direct Jenkins to promote jar files or container -images from staging areas to release areas. To trigger the action, create a releases/ or .releases/ -directory, place one or more release yaml files in it, and submit the change to Gerrit. Upon merge -of the change, Jenkins will sign the reference(s) extrapolated by log_dir and promote the artifact(s). - -Release jobs can also be triggered from Jenkins via the "Build with parameters" action, removing the -need for a release yaml file. The parameters must be filled out in the same way as a release file, -except for the special USE_RELEASE_FILE and DRY_RUN check boxes. The USE_RELEASE_FILE check box must -be unchecked if the job is expected to run with a release file, while passing the required information -as build parameters. Similarly, the DRY_RUN check box must be unchecked if the job needs to be tested -while skipping repository promotion to Nexus. +Self-serve release jobs allow a project team to direct Jenkins to +promote a jar file or container image from a staging area to a release +area. To trigger the action, create a releases/ or .releases/ +directory, add a release yaml file to it, and submit a change set with +one release yaml file to Gerrit. Upon merge of the change, Jenkins will +sign the reference extrapolated by log_dir and promote the artifact. The +expected format of the release yaml file appears in schemas and examples +below. + +The build node for maven and container 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. + +A Jenkins user can also trigger a release job via the "Build with +parameters" action, removing the need for a release yaml file. The +user must enter parameters in the same way as a release yaml file, +except for the special USE_RELEASE_FILE and DRY_RUN check boxes. The +user must uncheck the USE_RELEASE_FILE check box if the job should +run with a release file, while passing the required information as +build parameters. Similarly, the user must uncheck the DRY_RUN check +box to test the job while skipping repository promotion to Nexus. The special parameters are as follows:: @@ -27,15 +37,40 @@ The special parameters are as follows:: .. note:: - The release files regex is: (releases\/.*\.yaml|\.releases\/.*\.yaml). + The release file regex is: (releases\/.*\.yaml|\.releases\/.*\.yaml). In words, the directory name can be ".releases" or "releases"; the file - name can be any name with suffix ".yaml". + name can be anything with suffix ".yaml". + +The JSON schema for a maven release job appears below. + +.. code-block:: none + + --- + $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" + Example of a maven release file: .. code-block:: bash - $ cat releases/maven-1.0.0.yaml + $ cat releases/1.0.0-maven.yaml --- distribution_type: 'maven' version: '1.0.0' @@ -43,14 +78,50 @@ Example of a maven release file: log_dir: 'example-project-maven-stage-master/17/' -Example of a container release file: +The JSON schema for a container release job appears below. + +.. code-block:: none + + --- + $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" + ref: + type: "string" + + +An example of a container release file appears below. The job applies the +container_release_tag string to all released containers. The job uses the +per-container version strings to pull images from the container registry. .. code-block:: bash - $ cat releases/container-1.0.0.yaml + $ cat releases/1.0.0-container.yaml --- distribution_type: 'container' - version: '1.0.0' + container_release_tag: '1.0.0' project: 'test' containers: - name: test-backend @@ -61,7 +132,7 @@ Example of a container release file: .. note:: - Job should be appended under gerrit-maven-stage + Job should appear under gerrit-maven-stage Example of a terse Jenkins job to call the global-jjb macro: @@ -111,12 +182,14 @@ Create a Nexus account called ``'jenkins-release'`` with promote privileges. Gerrit ====== -Log into your Gerrit with ``YOU_RELEASE_USERNAME``, upload the public part of the ``ssh-key`` you -created earlier. Log out of Gerrit and log in again with your normal account for the next steps. +Log into your Gerrit with ``YOUR_RELEASE_USERNAME``, upload the public +part of the ``ssh-key`` you created earlier. Log out of Gerrit and log +in again with your normal account for the next steps. -In Gerrit create a new group called ``self-serve-release`` and give it direct push rights via ``All-Projects`` -Add ``YOUR_RELEASE_USERNAME`` to group ``self-serve-release`` and group ``Non-Interactive Users`` +In Gerrit create a new group called ``self-serve-release`` and give it +direct push rights via ``All-Projects`` Add ``YOUR_RELEASE_USERNAME`` +to group ``self-serve-release`` and group ``Non-Interactive Users`` In All project, grant group self-serve-release the following: @@ -135,8 +208,9 @@ In All project, grant group self-serve-release the following: Jenkins ======= -Add a global credential to Jenkins called ``jenkins-release`` and set the ID: ``'jenkins-release'`` -as its value insert the private half of the ``ssh-key`` that you created for your Gerrit user. +Add a global credential to Jenkins called ``jenkins-release`` and set +the ID: ``'jenkins-release'`` as its value insert the private half of +the ``ssh-key`` that you created for your Gerrit user. Add Global vars in Jenkins: Jenkins configure -> Global properties -> Environment variables @@ -154,8 +228,9 @@ Content: (Ask Andy for the public signing key) -----BEGIN PGP PUBLIC KEY BLOCK----- -Add or edit the managed file in Jenkins called ``lftoolsini``, appending a nexus section: -Jenkins Settings -> Managed files -> Add (or edit) -> Custom file +Add or edit the managed file in Jenkins called ``lftoolsini``, +appending a nexus section: Jenkins Settings -> Managed files -> Add +(or edit) -> Custom file .. code-block:: none @@ -166,10 +241,10 @@ Jenkins Settings -> Managed files -> Add (or edit) -> Custom file Ci-management ============= -Upgrade your project's global-jjb if needed, then add the following to your global defaults -file (e.g., jjb/defaults.yaml). +Upgrade your project's global-jjb if needed, then add the following to +your global defaults file (e.g., jjb/defaults.yaml). -.. code-block:: bash +.. code-block:: none jenkins-ssh-release-credential: 'jenkins-release' @@ -179,8 +254,8 @@ Macros lf-release ---------- -Release verify and merge jobs are the same except for their scm, trigger, and -builders definition. This anchor is the common template. +Release verify and merge jobs are the same except for their scm, +trigger, and builders definition. This anchor is the common template. Job Templates =============