From: Jessica Wagantall Date: Mon, 9 Sep 2019 20:54:53 +0000 (+0000) Subject: Merge "Fix self release script indent" X-Git-Tag: v0.43.0~3 X-Git-Url: https://gerrit.linuxfoundation.org/infra/gitweb?a=commitdiff_plain;h=0e21b89781f1e6def06ff6e6238107981c4ee75b;hp=8866ed8c8eb1c6a905db9d0a494ebe19ee7ab056;p=releng%2Fglobal-jjb.git Merge "Fix self release script indent" --- diff --git a/docs/jjb/lf-python-jobs.rst b/docs/jjb/lf-python-jobs.rst index c36ba8b9..4972e696 100644 --- a/docs/jjb/lf-python-jobs.rst +++ b/docs/jjb/lf-python-jobs.rst @@ -87,7 +87,7 @@ IQ Server. :java-version: Version of Java to use for the build. (default: openjdk8) :pre-build-script: Shell script to execute before the CLM builder. For example, install prerequisites or move files to the repo root. - (default: a string with only a comment) + (default: a string with a shell comment) :stream: Keyword used to represent a release code-name. Often the same as the branch. (default: master) :submodule-recursive: Whether to checkout submodules recursively. @@ -106,16 +106,21 @@ IQ Server. Python Sonar with Tox --------------------- -Sonar scans for Python based repos. This job will invoke tox to run tests -and gather coverage statistics from test results. Then the job invokes Maven -with a Sonar goal, which runs a plugin to publish results to a Sonar server. +Sonar scans for Python based repos. This job invokes tox to run tests and +gather coverage statistics from the test results, then invokes Maven to +publish the results to a Sonar server. -To get the Sonar coverage results, tox.ini needs to exist and be configured -with coverage commands to run. +To get the Sonar coverage results, file tox.ini must exist and contain coverage +commands to run. The coverage commands define the code that gets executed by the test suites. -It does not guarantee that the code tests executed properly, but it will help -pointing out the code that is not tested at all. +Checking coverage does not guarantee that the tests execute properly, but it +identifies code that is not executed by any test. + +This job reuses the Sonar builder used in Java/Maven projects which runs maven +twice. The first invocation does nothing for Python projects, so the job uses +the goal 'validate' by default. The second invocation publishes results using +the goal 'sonar:sonar' by default. For example: @@ -166,7 +171,7 @@ https://docs.sonarqube.org/display/PLUG/Python+Coverage+Results+Import :mvn-version: Version of maven to use. (default: mvn35) :pre-build-script: Shell script to execute before the Sonar builder. For example, install prerequisites or move files to the repo root. - (default: a string with only a comment) + (default: a string with a comment) :python-version: Python version (default: python2) :sonar-mvn-goal: The Maven goal to run the Sonar plugin. (default: sonar:sonar) :stream: Keyword used to represent a release code-name. @@ -219,7 +224,7 @@ following pyenv variables before running. :git-url: URL clone project from. (default: $GIT_URL/$PROJECT) :pre-build-script: Shell script to execute before the Tox builder. For example, install prerequisites or move files to the repo root. - (default: a string with only a comment) + (default: a string with a shell comment) :python-version: Version of Python to configure as a base in virtualenv. (default: python3) :stream: Keyword representing a release code-name. diff --git a/docs/jjb/lf-release-jobs.rst b/docs/jjb/lf-release-jobs.rst index 91ce7a05..9d5b1886 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,9 +78,43 @@ Example of a maven release file: log_dir: 'example-project-maven-stage-master/17/' -An example of a container release file appears below. The container_release_tag -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" + 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 @@ -74,7 +132,7 @@ strings are used to pull images from the container registry. .. 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: @@ -186,7 +244,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'