diff --git a/doc/source/core.rst b/doc/source/core.rst index 50764fd..4ef79a2 100644 --- a/doc/source/core.rst +++ b/doc/source/core.rst @@ -56,7 +56,7 @@ Re-approval =========== As covered in :ref:`automated-testing`, developers can take steps when -Jenkins tests fail. Core reviewers, like other developers, can use these +Zuul tests fail. Core reviewers, like other developers, can use these same steps when rerunning tests. Core reviewers have an additional tool for cases where gate testing fails due to reasons unrelated to the current change, re-approval. @@ -65,7 +65,7 @@ Core reviewers can approve changes again to trigger gate testing for that particular change. Core reviewers should still heed the advice in :ref:`automated-testing` to ensure that unrelated failures are properly tracked. Note that the change will directly enter the gate -pipeline if and only if it has already a +1 vote from Jenkins, +pipeline if and only if it has already a +1 vote from Zuul, otherwise it will first enter the check pipeline like a "recheck" would. diff --git a/doc/source/creators.rst b/doc/source/creators.rst index 28aba93..065c6d9 100644 --- a/doc/source/creators.rst +++ b/doc/source/creators.rst @@ -497,12 +497,12 @@ like:: See other files in the same directory for further examples. -.. _basic_jenkins_jobs: +.. _basic_zuul_jobs: -Add Basic Jenkins Jobs ----------------------- +Add Basic Zuul Jobs +------------------- -Test jobs run through Jenkins, and the jobs are defined using +Test jobs are run by Zuul, and the jobs are defined using jenkins-job-builder configuration files. .. note:: @@ -568,7 +568,7 @@ You can find more info about job templates in the beginning of Each of the jobs that you add a trigger for in ``zuul/layout.yaml`` needs to be defined first using jenkins-job-builder configuration -files as explained in :ref:`basic_jenkins_jobs`. +files as explained in :ref:`basic_zuul_jobs`. .. note:: diff --git a/doc/source/developers.rst b/doc/source/developers.rst index 6935490..08a4089 100644 --- a/doc/source/developers.rst +++ b/doc/source/developers.rst @@ -787,7 +787,7 @@ When a review has two +2 reviews and one of the core team believes it is ready to be merged, he or she should leave a +1 vote in the "Approved" category. You may do so by clicking the "Review" button again, with or without changing your code review vote and optionally -leaving a comment. When a +1 Approved review is received, Jenkins will +leaving a comment. When a +1 Approved review is received, Zuul will run tests on the change, and if they pass, it will be merged. A green checkmark indicates that the review has met the requirement @@ -804,20 +804,20 @@ Automated Testing ----------------- When a new patchset is uploaded to Gerrit, that project's "check" -tests are run on the patchset by Jenkins. Once completed the test -results are reported to Gerrit by Jenkins in the form of a Verified: +tests are run on the patchset by Zuul. Once completed the test +results are reported to Gerrit by Zuul in the form of a Verified: +/-1 vote. After code reviews have been completed and a change receives an Approved: +1 vote that project's "gate" tests are run -on the change by Jenkins. Jenkins reports the results of these tests +on the change by Zuul. Zuul reports the results of these tests back to Gerrit in the form of a Verified: +/-2 vote. Code merging will only occur after the gate tests have passed successfully and received a Verified: +2. You can view the state of tests currently being run on the `Zuul Status page `_. -If a change fails tests in Jenkins, please follow the steps below: +If a change fails tests in Zuul, please follow the steps below: -1. Jenkins leaves a comment in the review with links to the log files +1. Zuul leaves a comment in the review with links to the log files for the test run. Follow those links and examine the output from the test. It will include a console log, and in the case of unit tests, HTML output from the test runner, or in the case of a @@ -860,7 +860,7 @@ If a change fails tests in Jenkins, please follow the steps below: you do not find an existing bug, file a new one (be sure to include the error message and a link to the logs for the failure). If the problem is due to an infrastructure problem - (such as Jenkins or Gerrit), file (or search for) the bug against + (such as Zuul or Gerrit), file (or search for) the bug against the openstack-gate project. 5. It may also happen that the CI infrastructure somehow cannot finish @@ -1049,7 +1049,7 @@ comment notifying of merge failure. Each time a change merges, the "merge-check" pipeline verifies that all open changes on the same project are still mergeable. If any -job is not mergeable, Jenkins will give a -1 review and add a +job is not mergeable, Zuul will give a -1 review and add a comment notifying of merge failure. After a change is merged, project-specific post jobs are run.