This is an automated email from the ASF dual-hosted git repository.
git-site-role pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/beam.git
The following commit(s) were added to refs/heads/asf-site by this push:
new 947bb98 Publishing website 2018/10/29 21:40:21 at commit 0944d24
947bb98 is described below
commit 947bb98865c33488025090f768a440a12618f1f8
Author: jenkins <bui...@apache.org>
AuthorDate: Mon Oct 29 21:40:21 2018 +0000
Publishing website 2018/10/29 21:40:21 at commit 0944d24
---
.../contribute/postcommits-policies/index.html | 37 ++++++++++++++++++----
1 file changed, 31 insertions(+), 6 deletions(-)
diff --git
a/website/generated-content/contribute/postcommits-policies/index.html
b/website/generated-content/contribute/postcommits-policies/index.html
index 4fc7eca..62d4460 100644
--- a/website/generated-content/contribute/postcommits-policies/index.html
+++ b/website/generated-content/contribute/postcommits-policies/index.html
@@ -235,11 +235,11 @@ limitations under the License.
<p>Post-commit tests validate that Beam works correctly in a live environment.
The
tests also catch errors that are hard to predict in the design and
-implementation stages</p>
+implementation stages.</p>
<p>Even though post-commit tests run after the code is merged into the
repository,
it is important that the tests pass reliably. Jenkins executes post-commit
tests
-against the HEAD of the master branch. If post-commit tests fail, there is a
+against the HEAD of the <code class="highlighter-rouge">master</code> branch.
If post-commit tests fail, there is a
problem with the HEAD build. In addition, post-commit tests are time consuming
to run, and it is often hard to triage test failures.</p>
@@ -284,14 +284,39 @@ open a pull request with the proposed fix while doing
rollback.</p>
<h3 id="pr-rolled-back">My change was rolled back due to a test failure</h3>
+<p>After rollback there is time for deeper investigation. Start by looking at
the
+JIRA issue to see the background information for the rollback. These scenarios
+are all common:</p>
+
+<ul>
+ <li>Your change contained a bug.</li>
+ <li>Your change exposed an existing bug.</li>
+ <li>Your change exposed a bad test (flaky, overspecified, etc).</li>
+</ul>
+
+<p><em>These are all valid reasons for rollback. Maintaining clear signal is
the
+highest priority.</em></p>
+
+<p>The high level steps are the same:</p>
+
<ol>
- <li>Look at the JIRA issue to find the reason for the rollback.</li>
- <li>Fix your code and re-run the post-commit tests.</li>
- <li>Implement new pre-commit tests that will catch similar bugs before future
-code is merged into the repository.</li>
+ <li>Create a fix and re-run the post-commit tests.</li>
+ <li>Implement new pre-commit tests that will catch similar failures
+before future code is merged into the repository.</li>
<li>Open a new PR that contains your fix and the new pre-commit tests.</li>
</ol>
+<p>If the bug is not in your code, here is how to “create a fix”:</p>
+
+<ol>
+ <li>File a ticket for the existing bug, if it does not already exist.
+Remember that
+<a
href="/contribute/postcommits-policies-details/index.html#flake_is_failing">a
flaky test is a critical bug</a>. Other
+bad tests are similar: they may fail for arbitrary reasons having nothing
+to do with what is being tested, making our signal unreliable.</li>
+ <li>Mark the problematic test to be skipped, with a link to the JIRA
ticket.</li>
+</ol>
+
<h2 id="useful-links">Useful links</h2>
<ul>
