Bazel CI tests Bazel and a variety of open-source projects that use Bazel.
We also use the projects using Bazel to validate Bazel changes.
The Bazel CI:
If you wish to add or modify a configuration for one of the projects on Bazel CI, see the project owner documentation.
The CI uses the GitHub API and handles test runs automatically if bazel-io has write access to the repository.
The result of a build can be one of:
Success (job is green)
Unstable (job is yellow), if some tests failed.
The Blue Ocean View1 shows the failing platforms in Pipeline view and the list of failing tests in Tests view.
Failed (job is red), if compilation failed or configuration files are broken.
The Blue Ocean View1 shows the build breakage. If it doesn't, you should look at the full console log.
1 The Open Blue Ocean view is a Jenkins UI. There's a link to it on the default Jenkins UI, on the left side in the Job view.
Test logs are available under the artifacts list via the URL
Flaky tests can be analyzed with the Test Results Analyzer
The analyzer is available in the normal job view on the side menu (the one which shows the test's history).
The “Pipeline Steps” button on the side menu on a job view lets you examine each step of the Jenkins pipeline.
Looking for the enclosing workspace or node start step of another step gives you access to the workspace of that step.
Jenkins Blue Ocean UI has no good way to mark an unstable steps.
If a platform stage fails without clear sub-step failing, look for the last shell step in the platform stage view.
Tests are not ordered by platforms in the test view.
The Bazel CI can run presubmit tests for changes from GitHub and from Gerrit.
A GitHub pull request is tested when:
Pull request admins are the people from:
Jenkins considers those people to be admins whose visibility is public. To make someone public:
To test pull requests, bazel-io needs write access to the repository. This is always the case if the repository is in the
bazelbuild organization, otherwise you may need to grant access.
A Gerrit code review is tested when someone marks the code review as
Marking the code review as presubmit ready:
Verified-1depending on the result of the test
To retrigger a test, simply reset the
You can read the output the same way as of the postsubmit.
The Bazel CI can also do a “global test”.
A global test:
This report is at
https://ci.bazel.build/job/bazel/job/<nightly|release|presubmit>/<buildNumber>/Downstream_projects/. For example for the last nigthly run it will be at https://ci.bazel.build/job/bazel/job/nightly/lastBuild/Downstream_projects/ .
The way to read that report is as follows:
Newly failing jobs are problematic.
They are likely to indicate a failure due to a Bazel change. These make the build to be unstable (yellow).
Already failing jobs may be fine.
They mean that the job result is no worse than before. It is usually safe to ignore these failure, but we should aim to have none of them, because they might hide new regressions.
Passing jobs are safe to ignore.
In addition to testing all the jobs, the Global test handles pushing artifacts that are created by a release branch to GCS and to the GitHub release system.