X-Git-Url: https://gerrit.linuxfoundation.org/infra/gitweb?a=blobdiff_plain;f=docs%2Fjjb%2Flf-release-jobs.rst;h=98bc15378dbf8b8ca291c7b48d714e883d44e29d;hb=77b37fe255b0610d89478ab14cef0a9a6518a870;hp=d4af19b37100a160daf61eac2cf2e2f1cfca1cda;hpb=a43f74d71d53a8fb70cf0bed85bfa0449b80a0c2;p=releng%2Fglobal-jjb.git diff --git a/docs/jjb/lf-release-jobs.rst b/docs/jjb/lf-release-jobs.rst index d4af19b3..98bc1537 100644 --- a/docs/jjb/lf-release-jobs.rst +++ b/docs/jjb/lf-release-jobs.rst @@ -9,16 +9,15 @@ 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 -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. +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 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:: @@ -50,6 +49,12 @@ For example, the parameters for a Maven release are as follows:: USE_RELEASE_FILE = false DRY_RUN = false +It's recommended to use Semantic Versions (SemVer) for releases. Refer to +https://semver.org for more details on SemVer. For projects that do not +follow SemVer can use a build parameter (OVERRIDE_SEMVER_REGEX) with the +release job. This build param overrides the default SemVer regex. + + Maven Release Files ------------------- @@ -82,6 +87,8 @@ The following parameters must appear in a maven release yaml file. :git_tag: The tag string to sign and push to the Git repository. (default: the semantic version string) + :tag_release: Tag Gerrit Repo during the release process. + (default: true) The JSON schema for a maven release file appears below. @@ -132,6 +139,8 @@ The following parameters must appear in a container release yaml file. :git_tag: The tag string to sign and push to the Git repository. (default: the semantic version string) + :tag_release: Tag Gerrit Repo during the release process. + (default: true) The JSON schema for a container release file appears below. @@ -179,6 +188,8 @@ packages. :git_tag: The tag string to sign and push to the Git repository. (default: the semantic version string) + :tag_release: Tag Gerrit Repo during the release process. + (default: true) The JSON schema for a PyPI release file appears below. @@ -232,6 +243,8 @@ packages. :git_tag: The tag string to sign and push to the Git repository. (default: the semantic version string) + :tag_release: Tag Gerrit Repo during the release process. + (default: true) The JSON schema for a PackageCloud release file appears below. @@ -239,6 +252,15 @@ The JSON schema for a PackageCloud release file appears below. :language: yaml +Job Groups +========== + +Below is a list of Release job groups: + +.. literalinclude:: ../../jjb/lf-release-job-groups.yaml + :language: yaml + + Jenkins Jobs ------------