k3s/hack/jenkins
Zach Loafman 2d6c632de2 Revert "Revert "Merge pull request #28193 from zmerlynn/pull-ci-elsewhere""
Bring back #28193. We caught a break in
https://github.com/kubernetes/test-infra/issues/240 and discovered the
previous issue, fixed in
https://github.com/kubernetes/test-infra/pull/241 and
https://github.com/kubernetes/test-infra/pull/244, so I have a pretty
good handle on what was causing the previous bringup issues (and it
wasn't #28193). By the time this merges, we'll have good signal on GKE
in the `kubernetes-e2e-gke-updown` job.

This reverts commit ee1d480333.
2016-06-29 15:10:24 -07:00
..
test-image Download static docker binary into kubekins test image 2016-06-27 14:27:12 -07:00
OWNERS Create OWNERS for jenkins data 2016-04-28 18:03:11 -07:00
README.md Update Jenkins README to point to test-infra. 2016-05-02 13:43:35 -07:00
build.sh Skip gcloud update checks for Jenkins jobs. 2016-01-07 10:48:59 -08:00
dockerized-e2e-runner.sh Download static docker binary into kubekins test image 2016-06-27 14:27:12 -07:00
e2e-runner.sh Revert "Revert "Merge pull request #28193 from zmerlynn/pull-ci-elsewhere"" 2016-06-29 15:10:24 -07:00
gotest-dockerized.sh Download static docker binary into kubekins test image 2016-06-27 14:27:12 -07:00
gotest.sh Add Jenkins shell script to setup and run verification tests 2015-10-19 14:42:42 -07:00
test-dockerized.sh Merge pull request #27289 from mikedanese/split-verify 2016-06-16 19:37:06 -07:00
upload-finished.sh Pass --keepalive-time 2 to curl to fix unexpected EOF flakes 2016-06-09 17:37:25 -07:00
upload-started.sh Pass --keepalive-time 2 to curl to fix unexpected EOF flakes 2016-06-09 17:37:25 -07:00
upload-to-gcs.sh Upload build-log.txt if it exists. 2016-06-03 14:26:27 -07:00
verify-dockerized.sh split verify out of unit/integration suite 2016-06-16 18:23:03 -07:00
verify.sh Add Jenkins shell script to setup and run verification tests 2015-10-19 14:42:42 -07:00

README.md

Jenkins

Jenkins is a pluggable continuous integration system. The Google team is running two Jenkins servers in GCE for the Kubernetes project. The post-commit instance runs continuous builds, unit tests, integration tests, code verification tests, and end-to-end tests on multiple providers using the latest commits to the Kubernetes repo from the master and release branches. The PR Jenkins instance runs these tests on each PR by a trusted contributor, it but only runs a subset of the end-to-end tests and only on GCE.

General flow

The flow of the post-commit Jenkins instance:

  • Under the kubernetes-build job: Every 2 minutes, Jenkins polls for a batch of new commits, after which it runs the build.sh script (in this directory) on the latest tip. This results in build assets getting pushed to GCS and the latest.txt file in the ci bucket being updated.
  • On trigger, and every half hour (which effectively means all the time, unless we're failing cluster creation), e2e variants run, on the latest build assets in GCS:
    • kubernetes-e2e-gce: Standard GCE e2e.
    • kubernetes-e2e-gke: GKE provider e2e, with head k8s client and GKE creating clusters at its default version.
    • kubernetes-e2e-aws: AWS provider e2e. This only runs once a day.
  • Each job will not run concurrently with itself, so, for instance, Jenkins executor will only ever run one kubernetes-build job. However, it may run the jobs in parallel, i.e. kubernetes-build may be run at the same time as kubernetes-e2e-gce. For this reason, you may see your changes pushed to our GCS bucket rapidly, but they may take some time to fully work through Jenkins. Or you may get lucky and catch the train in 5 minutes.
  • There are many jobs not listed here, including upgrade tests, soak tests, and tests for previous releases.

Scripts

The scripts in this directory are directly used by Jenkins, either by curl from githubusercontent (if we don't have a git checkout handy) or by executing it from the git checkout. Since Jenkins is an entity outside this repository, it's tricky to keep documentation for it up to date quickly. However, the scripts themselves attempt to provide color for the configuration(s) that each script runs in.

GCS Log Format

Our upload-to-gcs.sh script runs at the start and end of every job. Logs on post-commit Jenkins go under gs://kubernetes-jenkins/logs/. Logs on PR Jenkins go under gs://kubernetes-jenkins-pull/pr-logs/pull/PULL_NUMBER/. Individual run logs go into the JOB_NAME/BUILD_NUMBER folder.

At the start of the job, it uploads started.json containing the version of Kubernetes under test and the timestamp.

At the end, it uploads finished.json containing the result and timestamp, as well as the build log into build-log.txt. Under artifacts/ we put our test results in junit_XY.xml, along with gcp resource lists and cluster logs.

It also updates latest-build.txt at the end to point to this build number. In the end, the directory structure looks like this:

gs://kubernetes-jenkins/logs/kubernetes-e2e-gce/
  latest-build.txt
  12345/
    build-log.txt
    started.json
    finished.json
    artifacts/
      gcp-resources-{before, after}.txt
      junit_{00, 01, ...}.xml
      jenkins-e2e-master/{kube-apiserver.log, ...}
      jenkins-e2e-minion-abcd/{kubelet.log, ...}
  12344/
    ...

The munger uses latest-build.txt and the JUnit reports to figure out whether or not the job is healthy.

Job Builder

New jobs should be specified as YAML files to be processed by Jenkins Job Builder. The YAML files live in jenkins/job-configs and its subfolders in the kubernetes/test-infra repository. Jenkins runs Jenkins Job Builder in a Docker container defined in job-builder-image, and triggers it using update-jobs.sh. Jenkins Job Builder uses a config file called jenkins_jobs.ini which contains the location and credentials of the Jenkins server.

E2E Job definitions are templated to avoid code duplication. To add a new job, add a new entry to the appropriate project. This is an example of a commit which does this. If necessary, create a new project, as in this commit.

Analytics