+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::
+
+ GERRIT_BRANCH = master
+ VERSION = 1.0.0
+ LOG_DIR = example-project-maven-stage-master/17/
+ DISTRIBUTION_TYPE = maven
+ USE_RELEASE_FILE = false
+ DRY_RUN = false