Remove lftools install step from clm job

[releng/global-jjb.git] / README.md

diff --git a/README.md b/README.md
index 63cdff3..c1522bc 100644 (file)
--- a/README.md
+++ b/README.md
@@ -1,9 +1,9 @@
 # Global JJB
 
 # Global JJB
 

-The purpose of this repository is store generically define reusable JJB
-templates that can be deployed across LF projects.
+The purpose of this repository is store generically defined, reusable JJB
+templates, deployable across LF projects.

 
 

-The following variables are necessary to be defined in the Jenkins server as
+Define the following variables in the Jenkins server as

 global environment variables as scripts in this repo expect these variables to
 be available.
 
 global environment variables as scripts in this repo expect these variables to
 be available.
 


@@ -17,7 +17,8 @@ LOGS_SERVER=https://logs.opendaylight.org
 NEXUS_URL=https://nexus.opendaylight.org
 SILO=releng
 ```
 NEXUS_URL=https://nexus.opendaylight.org
 SILO=releng
 ```

-Note: **GIT_CLONE_URL** is only used by Github projects as this
+
+Note: Use **GIT_CLONE_URL** for GitHub projects as this

 will be different from the URL used the poperties
 configuration.
 
 will be different from the URL used the poperties
 configuration.
 


@@ -41,16 +42,16 @@ configuration.
 
 ## Installing global-jjb
 
 
 ## Installing global-jjb
 

-global-jjb should be deployed in the ci-management repository's jjb directory as
-a submodule. global-jjb is versioned and tagged in Gerrit so installing,
-upgrading, and rolling back changes should be simple via the Gerrit tag system.
+Deploy global-jjb in the ci-management repository's jjb directory as
+a submodule. Installing, upgrading, and rolling back changes is simple via the
+versioned git tags.

 
 ```
     # Choose a global-jjb version to install
     GLOBAL_JJB_VERSION=v0.1.0
 
     # Add the new submodule to ci-management's jjb directory.
 
 ```
     # Choose a global-jjb version to install
     GLOBAL_JJB_VERSION=v0.1.0
 
     # Add the new submodule to ci-management's jjb directory.

-    # Note: Only needs to be performed once per ci-management repo.
+    # Note: Perform once per ci-management repo.

     cd jjb/
     git submodule add https://gerrit.linuxfoundation.org/infra/releng/global-jjb
 
     cd jjb/
     git submodule add https://gerrit.linuxfoundation.org/infra/releng/global-jjb
 


@@ -69,28 +70,40 @@ upgrading, and rolling back changes should be simple via the Gerrit tag system.
 
 ## Parameters stored in defaults.yaml
 
 
 ## Parameters stored in defaults.yaml
 

-There are a few project specific parameters that should be stored in the
-ci-management repo's defaults.yaml file.
+Configure the following parameters in the ci-management repo's
+defaults.yaml file.

 
 

-**gerrit-server-name**: The name of the Gerrit Server as defined in Gerrit
-Trigger global configuration.
+**gerrit-server-name**: The name of the Gerrit Server as defined
+in Gerrit Trigger global configuration.

 
 

-**jenkins-ssh-credential**: The name of the Jenkins Credential to use for ssh
-connections.
+**jenkins-ssh-credential**: The name of the Jenkins Credential to
+use for ssh connections.

 
 

-If you are using GitHub then there are two more parameters which
-will need to be placed in the defaults.yaml
+If you are using GitHub then configure the following parameters
+in defaults.yaml

 
 

-**git-url**: This should be set to the base URL of your GitHub. In
-general this should be https://github.com. If you are using GitHub
-Enterprise, or some other GitHub-style system, then it should be
-whatever your installation base URL is.
+**git-url**: Set this to the base URL of your GitHub repo. In
+general this should be <https://github.com>. If you are using
+GitHub Enterprise, or some other GitHub-style system, then it
+should be whatever your installation base URL is.

 
 

-**git-clone-url**: This is the clone prefix used by GitHub jobs. This
-should be set to either the same thing as **git-url** or the
+**git-clone-url**: This is the clone prefix used by GitHub jobs.
+Set this to either the same thing as **git-url** or the

 'git@github.com:' including the trailing ':'
 
 'git@github.com:' including the trailing ':'
 

-**github-org**: The name of the GitHub organization.
+**github-org**: The name of the GitHub organization interpolated
+into the scm config.
+
+**github_pr_org**: The name of the GitHub organization. All members
+of this organization will be able to trigger any job using the
+`lf-infra-github-pr` macro.
+
+**github_pr_whitelist**: List of GitHub members you wish to be able to
+trigger any job that uses the `lf-infra-github-pr-trigger` macro.
+
+**github_pr_admin_list**: List of GitHub members that will have admin
+privileges on any job using the `lf-infra-github-pr-trigger`
+macro.

 
 defaults.yaml:
 
 
 defaults.yaml:
 


@@ -102,6 +115,12 @@ defaults.yaml:
     jenkins-ssh-credential: opendaylight-jenkins-ssh
     gerrit-server-name: OpenDaylight
     github-org: lfit
     jenkins-ssh-credential: opendaylight-jenkins-ssh
     gerrit-server-name: OpenDaylight
     github-org: lfit

+    github_pr_whitelist:
+      - jpwku
+      - tykeal
+      - zxiiro
+    github_pr_admin_list:
+      - tykeal

 ```
 
 ## Config File Management
 ```
 
 ## Config File Management


@@ -114,7 +133,7 @@ credentials for the logs user in Nexus.
 
 ## Deploying ci-jobs
 
 
 ## Deploying ci-jobs
 

-The CI job group contains multiple jobs that should be deployed in all LF
+The CI job group contains jobs that should deploy in all LF

 Jenkins infra. The minimal configuration needed to deploy the ci-management
 jobs is as follows which deploys the **{project-name}-ci-jobs** job group as
 defined in **lf-ci-jobs.yaml**.
 Jenkins infra. The minimal configuration needed to deploy the ci-management
 jobs is as follows which deploys the **{project-name}-ci-jobs** job group as
 defined in **lf-ci-jobs.yaml**.


@@ -144,13 +163,68 @@ Optional parameters:
 **branch**: is the git branch to build from.
 **jjb-version**: is the version of JJB to install in the build minion.
 
 **branch**: is the git branch to build from.
 **jjb-version**: is the version of JJB to install in the build minion.
 

+## Deploying packer-jobs
+
+The packer job group contains jobs to build custom minion images. The minimal
+configuration needed to deploy the packer jobs is as follows which deploys the
+**{project-name}-packer-jobs** job group as defined in **lf-ci-jobs.yaml**.
+
+ci-management.yaml:
+
+```
+- project:
+    name: packer-jobs
+
+    jobs:
+      - '{project-name}-packer-jobs'
+
+    project: ci-management
+    project-name: ci-management
+    branch: master
+    build-node: centos7-basebuild-2c-1g
+
+    platforms:
+      - centos
+      - ubuntu-14.04
+      - ubuntu-16.04
+
+    templates:
+      - devstack
+      - docker
+      - gbp
+      - java-builder
+      - mininet
+
+    exclude:
+      - platforms: centos
+        templates: gbp
+      - platforms: centos
+        templates: mininet
+```
+
+Required parameters:
+
+**project**: is the project repo as defined in source control.
+**project-name**: is a custom name to call the job in Jenkins.
+**build-node**: is the name of the builder to use when building (Jenkins label).
+**platforms**: is a list of supported platforms.
+**templates**: is a list of supported templates.
+
+Optional parameters:
+
+**branch**: is the git branch to build from.
+**packer-version**: is the version of packer to install in the build minion,
+when packer is not available.
+**exclude**: is a combination of platforms and templates which are not required
+to build.
+

 ## Deploying Python jobs
 
 We provide the following Python jobs templates:
 
 ### {project-name}-tox-verify-{stream}
 
 ## Deploying Python jobs
 
 We provide the following Python jobs templates:
 
 ### {project-name}-tox-verify-{stream}
 

-This job can be used to call python-tox to run builds and tests. The most common
+Use this job to call python-tox to run builds and tests. The most common

 usage of this job is to run the Coala linter against projects.
 
 ```
 usage of this job is to run the Coala linter against projects.
 
 ```


@@ -170,7 +244,7 @@ Required parameters:
 **project**: is the project repo as defined in source control.
 **project-name**: is a custom name to call the job in Jenkins.
 **build-node**: is the name of the builder to use when building (Jenkins label).
 **project**: is the project repo as defined in source control.
 **project-name**: is a custom name to call the job in Jenkins.
 **build-node**: is the name of the builder to use when building (Jenkins label).

-**stream**: typically `master` or matching whatever branch is being built. This
+**stream**: typically `master` or matching the build branch. This

             is a useful keywords to map a release codename to a branch. For
             example OpenDaylight uses this to map stream=carbon to
             branch=stable/carbon.
             is a useful keywords to map a release codename to a branch. For
             example OpenDaylight uses this to map stream=carbon to
             branch=stable/carbon.


@@ -188,21 +262,31 @@ There are 2 ways supported for archiving log information:
 
 1) Job creates $WORKSPACE/archives directory and places logs there
 
 
 1) Job creates $WORKSPACE/archives directory and places logs there
 

-In this method the entire archives directory will be pushed to the log server
+This method pushes the entire archives directory to the log server

 in the same structure as configured in the archives directory.
 
 2) Via job variable ARCHIVE_ARTIFACTS using globstar patterns.
 
 in the same structure as configured in the archives directory.
 
 2) Via job variable ARCHIVE_ARTIFACTS using globstar patterns.
 

-In this method a job can define a globstar for example ``**/*.log`` which then
+In this method a job can define a globstar for example `**/*.log` which then

 causes the archive script to do a globstar search for that pattern and archives
 any files it finds matching.
 
 causes the archive script to do a globstar search for that pattern and archives
 any files it finds matching.
 

+## Overriding merge and verify triggers
+
+The default trigger conditions for Merge and Verify job types are overrideable
+in a project configuration by overriding the following variables:
+
+- gerrit_merge_triggers
+- gerrit_verify_triggers
+
+These variables take a list of trigger-on values as defined in JJB docs here:
+<https://docs.openstack.org/infra/jenkins-job-builder/triggers.html#triggers.gerrit>
+

 ## Appendix
 
 ### ShellCheck
 
 ## Appendix
 
 ### ShellCheck
 

-If ShellCheck is being used to lint global-jjb or any projects that include
+When using ShellCheck to lint global-jjb or any projects that include

 global-jjb as part of their project (common with ci-management repos) then
 global-jjb as part of their project (common with ci-management repos) then

-a minimum version of ShellCheck 0.4.x is required as the shell scripts in
-this repo uses annotations that were introduced in 0.4..
-
+we require version 0.4.x of ShellCheck installed on the build vms. This version
+introduces annotations used by shell scripts in this repo.