X-Git-Url: https://gerrit.linuxfoundation.org/infra/gitweb?a=blobdiff_plain;f=docs%2Fjjb%2Flf-release-jobs.rst;h=d0f5340feb34f7d005ba23b161f7a377dadf79b3;hb=d0dfd24055995c4a2ed27fb7bc9e3dee65ba0d16;hp=562dcef07cbfb74034c1511813ea07a6df6ceaa9;hpb=54932faaba0a4de202d642e529dd74e4d6a6fbde;p=releng%2Fglobal-jjb.git diff --git a/docs/jjb/lf-release-jobs.rst b/docs/jjb/lf-release-jobs.rst index 562dcef0..d0f5340f 100644 --- a/docs/jjb/lf-release-jobs.rst +++ b/docs/jjb/lf-release-jobs.rst @@ -8,24 +8,23 @@ 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 -exactly 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 is shown in -examples below. +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 release job can also be triggered from Jenkins via the "Build with +A Jenkins user can also trigger a release job 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 yaml file, +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 -USE_RELEASE_FILE check box must be unchecked if the job is expected to +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 DRY_RUN check box must be unchecked -if the job needs to be tested while skipping repository promotion to -Nexus. +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:: @@ -42,6 +41,31 @@ The special parameters are as follows:: In words, the directory name can be ".releases" or "releases"; the file 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 @@ -54,18 +78,59 @@ Example of a maven release file: log_dir: 'example-project-maven-stage-master/17/' -An example of a container release file appears below. The first -version string is applied to all released containers. The -per-container version strings are used to pull images from the -container registry. +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" + container_pull_registry" + type: "string" + container_push_registry" + type: "string" + ref: + type: "string" + + +An example of a container release file appears below. The job tags the +git repository at the specified commit reference. 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/1.0.0-container.yaml --- distribution_type: 'container' - version: '1.0.0' + container_release_tag: '1.0.0' + container_pull_registry: 'nexus.onap.org:10003" + container_push_registry: 'nexus.onap.org:10002" project: 'test' + ref: d1b9cd2dd345fbeec0d3e2162e008358b8b663b2 containers: - name: test-backend version: 1.0.0-20190806T184921Z @@ -73,20 +138,20 @@ container registry. version: 1.0.0-20190806T184921Z -.. note:: - - Job should be appended under gerrit-maven-stage - -Example of a terse Jenkins job to call the global-jjb macro: +Example of a Jenkins job configuration that uses the global-jjb +templates for Gerrit: .. code-block:: none - - gerrit-maven-stage: - sign-artifacts: true - build-node: centos7-docker-8c-8g - maven-versions-plugin: true - - '{project-name}-gerrit-release-jobs': - build-node: centos7-docker-8c-8g + - project: + name: my-project-release + project: my-project + project-name: my-project + build-node: centos7-docker-4c-4g + mvn-settings: my-project-settings + jobs: + - '{project-name}-gerrit-release-jobs' + .. note:: @@ -161,6 +226,12 @@ Jenkins configure -> Global properties -> Environment variables ``RELEASE_USERNAME = YOUR_RELEASE_USERNAME`` ``RELEASE_EMAIL = YOUR_RELEASE_EMAIL`` + +.. note:: + + Add these variables to your global-vars-$SILO.sh file or they will + be overwritten. + Jenkins configure -> Managed Files -> Add a New Config -> Custom File id: signing-pubkey @@ -187,7 +258,7 @@ Ci-management 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'