OpenShift Jenkins CI CD job for building & testing Service Catalog prior to 4.0

The Service Catalog has a Jenkins job within OpenShift to build and run Catalog tests as part of the CI/CD process. The job is located at https://github.com/openshift/aos-cd-jobs/blob/master/sjb/config/test_cases/test_pull_request_origin_service_catalog.yml

Currently the job is not automatically run. The end goal is to get this job to run when any service catalog related code is updated. To run the job, add /test service-catalog to a PR.

The job can be modified by editing test_pull_request_origin_service_catalog.yml. After updating the job YAML, you must generate the XML which is used to actually to define the job tasks. Both the YAML source and the generated XML must be updated in GITHUB. Additionally, the XML must be manually pushed to the Jenkins servers once the PR is merged.

The Service Catalog job is still in its infancy and I have been taking short cuts with the process I generally follow:

1. Edit the Service Catalog job YAML (sjb/config/test_cases/test_pull_request_origin_service_catalog.yml)
2. run sjb/generate.py
3. push the changes to Jenkins with sjb/push-update.sh sjb/generated/test_pull_request_origin_service_catalog.xml
4. Run the job by adding /test service-catalog in a PR comment
5. Once satisfied, create a PR to merge the yaml and and xml.

This does not follow the flow described in https://github.com/openshift/aos-cd-jobs#custom-xml-generator-configuration-under-sjb - - there are specific steps we are supposed to follow when making changes to ensure you do not break the pipeline. IE copy the existing job to a new temporary name, make changes, set the type field under sync_repos, push the temp job to Jenkins.... We need to get more details around this, I don't fully understand the flow.

General OpenShift Jenkins info & background: https://github.com/openshift/aos-cd-jobs

You must have a Jenkins account to update the job (see https://mojo.redhat.com/docs/DOC-1081313#jive_content_id_Jenkins for steps to follow to request the account). You will get a userid/password that must be set as shell variables to execute the sjb/push-update.sh.

The structure of the job yaml is pretty straight forward. Each task builds upon the previous task. As an example, here are several of the initial catalog specific tasks:

- type: "script"
  title: "build service-catalog user-broker image"
  repository: "origin"
  timeout: 1800
  script: |-
    REGISTRY=openshift/ NO_DOCKER=1 make -C cmd/service-catalog/go/src/github.com/kubernetes-incubator/service-catalog user-broker-image
- type: "script"
  title: "build Service Catalog binary"
  repository: "origin"
  timeout: 1800
  script: |-
    unset GOPATH; cmd/service-catalog/go/src/github.com/kubernetes-incubator/service-catalog/hack/build-go.sh
- type: "script"
  title: "run Service Catalog unit tests"
  repository: "origin"
  timeout: 1800
  script: |-
    NO_DOCKER=1 make -C cmd/service-catalog/go/src/github.com/kubernetes-incubator/service-catalog test-unit

Future enhancements should include running integration tests and formatting the output of the go unit tests and e2e in junit format to facilitate Jenkins reporting.

Steve Kuznetsov was instrumental in getting the initial job setup and working. He can assist with configuring the job for debugging which keeps CI/CD machine for this job in it's last run state enabling you to SSH in and review logs and execute commands in the real environment where the job runs.