Add testing framework for Groovy pipelines

 - Create groovy_libraries for everything under jenkins/lib/src/... Should catch
   most groovy syntax errors.
 - Add a dummy test for bazelJob that at least verify that we can parse the library.
   This test is just printing the stack trace, ultimately it should be improved to
   parse the output of the pipeline and the mocks should be improved to be able
   to deal with various code path.

Change-Id: I834b806c48640da923ae91269350330b584af7cd
15 files changed
tree: 8e5e5e297e17e3d344c2fed6144e1425dd9fbe07
  1. 3rdparty/
  2. base/
  3. docs/
  4. gce/
  5. gcr/
  6. gerrit-github-sync/
  7. jenkins/
  8. mac/
  9. templating/
  10. .gitignore
  11. AUTHORS
  12. CONTRIBUTING.md
  13. CONTRIBUTORS
  14. LICENSE.txt
  15. README.md
  16. WORKSPACE
README.md

Bazel continous integration setup

This workspace contains the setup for the continuous integration system of Bazel. This setup is based on docker images built by bazel.

For users of Bazel continuous integration system

If you are a user of the CI system, you might be interested in the following document:

  • owner: explains how to add a job for a repository owner.
  • user: explains how to use the CI system for a Bazel contributor.

For maintainers of Bazel continuous integration system

Make sure you have a Bazel installed with a recent enough version of it. Also make sure gcloud and docker are correctly configured on your machine. Only docker version 1.10 or later is supported.

Finally, our docker rules needs authentication which is configured with the credential helper:

gcloud components install docker-credential-gcr
export DOCKER_CONFIG="$(docker-credential-gcr configure-docker | sed -E 's|/config.json .*$||')"

You might want to permanently set your DOCKER_CONFIG environment, e.g. in your ~/.bash_profile:

echo "export DOCKER_CONFIG='${DOCKER_CONFIG}'" >> ~/.bash_profile

More documentation:

  • init.sh: initializes the whole CI platform. This may delete VMs and do other irreversible changes, so handle with care.
  • vm.sh: lets you control the machines (e.g. start/stop them, create/delete/reimage them), including the Jenkins controller and the executor nodes.
  • workflow: explains the CI workflow, and how you can test local changes with jenkins-staging
  • jobs: explains what jobs are running on the CI