You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@spark.apache.org by sr...@apache.org on 2023/02/25 20:10:44 UTC

[spark-website] branch asf-site updated: Remove Jenkins from pages

This is an automated email from the ASF dual-hosted git repository.

srowen pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/spark-website.git


The following commit(s) were added to refs/heads/asf-site by this push:
     new 48d982a6f1 Remove Jenkins from pages
48d982a6f1 is described below

commit 48d982a6f19bebf60584b8aa8c287ecf2adc81c9
Author: Bjørn <bj...@gmail.com>
AuthorDate: Sat Feb 25 14:10:36 2023 -0600

    Remove Jenkins from pages
    
    <!-- *Make sure that you generate site HTML with `bundle exec jekyll build`, and include the changes to the HTML in your pull request. See README.md for more information.* -->
    
    `bundle exec jekyll build --watch`
    
    Removed info about Jerkins from the developer-tools.md fil
    
          Regenerating: 1 file(s) changed at 2023-02-25 15:14:42
                        developer-tools.md
                        ...done in 2.778396909 seconds.
    
    We don't use Jenkins anymore so we can remove this info.
    
    Author: Bjørn <bj...@gmail.com>
    
    Closes #442 from bjornjorgensen/remove-Jenkins-form-dev.tools.
---
 contributing.md           | 15 ---------------
 developer-tools.md        | 23 -----------------------
 release-process.md        | 10 ----------
 site/contributing.html    | 21 ---------------------
 site/developer-tools.html | 24 ------------------------
 site/release-process.html |  9 ---------
 6 files changed, 102 deletions(-)

diff --git a/contributing.md b/contributing.md
index b127afe919..8f0ec49869 100644
--- a/contributing.md
+++ b/contributing.md
@@ -387,21 +387,6 @@ will trigger workflows "On pull request*" (on Spark repo) that will look/watch f
 1. The related JIRA, if any, will be marked as "In Progress" and your pull request will 
 automatically be linked to it. There is no need to be the Assignee of the JIRA to work on it, 
 though you are welcome to comment that you have begun work.
-1. The Jenkins automatic pull request builder will test your changes
-     1. If it is your first contribution, Jenkins will wait for confirmation before building 
-     your code and post "Can one of the admins verify this patch?"
-     1. A committer can authorize testing with a comment like "ok to test"
-     1. A committer can automatically allow future pull requests from a contributor to be 
-     tested with a comment like "Jenkins, add to whitelist"
-1. After about 2 hours, Jenkins will post the results of the test to the pull request, along 
-with a link to the full results on Jenkins.
-1. Watch for the results, and investigate and fix failures promptly
-     1. Fixes can simply be pushed to the same branch from which you opened your pull request
-     1. Jenkins will automatically re-test when new commits are pushed
-     1. If the tests failed for reasons unrelated to the change (e.g. Jenkins outage), then a 
-     committer can request a re-test with "Jenkins, retest this please".
-     Ask if you need a test restarted. If you were added by "Jenkins, add to whitelist" from a
-     committer before, you can also request the re-test.
 1. If there is a change related to SparkR in your pull request, AppVeyor will be triggered
 automatically to test SparkR on Windows, which takes roughly an hour. Similarly to the steps
 above, fix failures and push new commits which will request the re-test in AppVeyor.
diff --git a/developer-tools.md b/developer-tools.md
index c8b8892b89..fdbf88796e 100644
--- a/developer-tools.md
+++ b/developer-tools.md
@@ -240,18 +240,6 @@ sufficient to run a test from the command line:
 build/sbt "testOnly org.apache.spark.rdd.SortingSuite"
 ```
 
-<h3>Running different test permutations on Jenkins</h3>
-
-When running tests for a pull request on Jenkins, you can add special phrases to the title of 
-your pull request to change testing behavior. This includes:
-
-- `[test-maven]` - signals to test the pull request using maven
-- `[test-hadoop2.7]` - signals to test using Spark's Hadoop 2.7 profile
-- `[test-hadoop3.2]` - signals to test using Spark's Hadoop 3.2 profile
-- `[test-hadoop3.2][test-java11]` - signals to test using Spark's Hadoop 3.2 profile with JDK 11
-- `[test-hive1.2]` - signals to test using Spark's Hive 1.2 profile
-- `[test-hive2.3]` - signals to test using Spark's Hive 2.3 profile
-
 <h3>Binary compatibility</h3>
 
 To ensure binary compatibility, Spark uses [MiMa](https://github.com/typesafehub/migration-manager).
@@ -274,17 +262,6 @@ A binary incompatibility reported by MiMa might look like the following:
 [error] filter with: ProblemFilters.exclude[DirectMissingMethodProblem]("org.apache.spark.SomeClass.this")
 ```
 
-If you open a pull request containing binary incompatibilities anyway, Jenkins
-will remind you by failing the test build with the following message:
-
-```
-Test build #xx has finished for PR yy at commit ffffff.
-
-  This patch fails MiMa tests.
-  This patch merges cleanly.
-  This patch adds no public classes.
-```
-
 <h4>Solving a binary incompatibility</h4>
 
 If you believe that your binary incompatibilies are justified or that MiMa
diff --git a/release-process.md b/release-process.md
index 3f6305984f..2133010840 100644
--- a/release-process.md
+++ b/release-process.md
@@ -140,11 +140,6 @@ The main step towards preparing a release is to create a release branch. This is
 standard Git branching mechanism and should be announced to the community once the branch is
 created.
 
-It is also good to set up Jenkins jobs for the release branch once it is cut to
-ensure tests are passing. These are jobs like
-https://amplab.cs.berkeley.edu/jenkins/view/Spark%20QA%20Test/job/spark-branch-2.3-test-maven-hadoop-2.7/ .
-Consult Josh Rosen and Shane Knapp for help with this. Also remember to add the newly-added jobs
-to the test dashboard at https://amplab.cs.berkeley.edu/jenkins/view/Spark%20QA%20Test%20(Dashboard)/ .
 
 <h3>Cutting a release candidate</h3>
 
@@ -165,11 +160,6 @@ Verify from `git log` whether they are actually making it in the new RC or not.
 with `release-notes` label, and make sure they are documented in relevant migration guide for breaking
 changes or in the release news on the website later.
 
-
-Also check that all build and test passes are green from the RISELab Jenkins: https://amplab.cs.berkeley.edu/jenkins/ particularly look for Spark Packaging, QA Compile, QA Test.
-Note that not all permutations are run on PR therefore it is important to check Jenkins runs.
-
-
 To cut a release candidate, there are 4 steps:
 1. Create a git tag for the release candidate.
 1. Package the release binaries & sources, and upload them to the Apache staging SVN repo.
diff --git a/site/contributing.html b/site/contributing.html
index f4cff06ca4..a16d1894f1 100644
--- a/site/contributing.html
+++ b/site/contributing.html
@@ -555,27 +555,6 @@ will trigger workflows &#8220;On pull request*&#8221; (on Spark repo) that will
   <li>The related JIRA, if any, will be marked as &#8220;In Progress&#8221; and your pull request will 
 automatically be linked to it. There is no need to be the Assignee of the JIRA to work on it, 
 though you are welcome to comment that you have begun work.</li>
-  <li>The Jenkins automatic pull request builder will test your changes
-    <ol>
-      <li>If it is your first contribution, Jenkins will wait for confirmation before building 
-  your code and post &#8220;Can one of the admins verify this patch?&#8221;</li>
-      <li>A committer can authorize testing with a comment like &#8220;ok to test&#8221;</li>
-      <li>A committer can automatically allow future pull requests from a contributor to be 
-  tested with a comment like &#8220;Jenkins, add to whitelist&#8221;</li>
-    </ol>
-  </li>
-  <li>After about 2 hours, Jenkins will post the results of the test to the pull request, along 
-with a link to the full results on Jenkins.</li>
-  <li>Watch for the results, and investigate and fix failures promptly
-    <ol>
-      <li>Fixes can simply be pushed to the same branch from which you opened your pull request</li>
-      <li>Jenkins will automatically re-test when new commits are pushed</li>
-      <li>If the tests failed for reasons unrelated to the change (e.g. Jenkins outage), then a 
-  committer can request a re-test with &#8220;Jenkins, retest this please&#8221;.
-  Ask if you need a test restarted. If you were added by &#8220;Jenkins, add to whitelist&#8221; from a
-  committer before, you can also request the re-test.</li>
-    </ol>
-  </li>
   <li>If there is a change related to SparkR in your pull request, AppVeyor will be triggered
 automatically to test SparkR on Windows, which takes roughly an hour. Similarly to the steps
 above, fix failures and push new commits which will request the re-test in AppVeyor.</li>
diff --git a/site/developer-tools.html b/site/developer-tools.html
index 542a75f0f2..09f55cd451 100644
--- a/site/developer-tools.html
+++ b/site/developer-tools.html
@@ -350,20 +350,6 @@ sufficient to run a test from the command line:</p>
 <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>build/sbt "testOnly org.apache.spark.rdd.SortingSuite"
 </code></pre></div></div>
 
-<h3>Running different test permutations on Jenkins</h3>
-
-<p>When running tests for a pull request on Jenkins, you can add special phrases to the title of 
-your pull request to change testing behavior. This includes:</p>
-
-<ul>
-  <li><code class="language-plaintext highlighter-rouge">[test-maven]</code> - signals to test the pull request using maven</li>
-  <li><code class="language-plaintext highlighter-rouge">[test-hadoop2.7]</code> - signals to test using Spark&#8217;s Hadoop 2.7 profile</li>
-  <li><code class="language-plaintext highlighter-rouge">[test-hadoop3.2]</code> - signals to test using Spark&#8217;s Hadoop 3.2 profile</li>
-  <li><code class="language-plaintext highlighter-rouge">[test-hadoop3.2][test-java11]</code> - signals to test using Spark&#8217;s Hadoop 3.2 profile with JDK 11</li>
-  <li><code class="language-plaintext highlighter-rouge">[test-hive1.2]</code> - signals to test using Spark&#8217;s Hive 1.2 profile</li>
-  <li><code class="language-plaintext highlighter-rouge">[test-hive2.3]</code> - signals to test using Spark&#8217;s Hive 2.3 profile</li>
-</ul>
-
 <h3>Binary compatibility</h3>
 
 <p>To ensure binary compatibility, Spark uses <a href="https://github.com/typesafehub/migration-manager">MiMa</a>.</p>
@@ -384,16 +370,6 @@ not introduce binary incompatibilities before opening a pull request.</p>
 [error] filter with: ProblemFilters.exclude[DirectMissingMethodProblem]("org.apache.spark.SomeClass.this")
 </code></pre></div></div>
 
-<p>If you open a pull request containing binary incompatibilities anyway, Jenkins
-will remind you by failing the test build with the following message:</p>
-
-<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Test build #xx has finished for PR yy at commit ffffff.
-
-  This patch fails MiMa tests.
-  This patch merges cleanly.
-  This patch adds no public classes.
-</code></pre></div></div>
-
 <h4>Solving a binary incompatibility</h4>
 
 <p>If you believe that your binary incompatibilies are justified or that MiMa
diff --git a/site/release-process.html b/site/release-process.html
index 1abae4a3fa..68ed1e9499 100644
--- a/site/release-process.html
+++ b/site/release-process.html
@@ -264,12 +264,6 @@ for more details.</p>
 standard Git branching mechanism and should be announced to the community once the branch is
 created.</p>
 
-<p>It is also good to set up Jenkins jobs for the release branch once it is cut to
-ensure tests are passing. These are jobs like
-https://amplab.cs.berkeley.edu/jenkins/view/Spark%20QA%20Test/job/spark-branch-2.3-test-maven-hadoop-2.7/ .
-Consult Josh Rosen and Shane Knapp for help with this. Also remember to add the newly-added jobs
-to the test dashboard at https://amplab.cs.berkeley.edu/jenkins/view/Spark%20QA%20Test%20(Dashboard)/ .</p>
-
 <h3>Cutting a release candidate</h3>
 
 <p>If this is not the first RC, then make sure that the JIRA issues that have been solved since the
@@ -286,9 +280,6 @@ and click on the version link of its Target Versions field)</p>
 with <code class="language-plaintext highlighter-rouge">release-notes</code> label, and make sure they are documented in relevant migration guide for breaking
 changes or in the release news on the website later.</p>
 
-<p>Also check that all build and test passes are green from the RISELab Jenkins: https://amplab.cs.berkeley.edu/jenkins/ particularly look for Spark Packaging, QA Compile, QA Test.
-Note that not all permutations are run on PR therefore it is important to check Jenkins runs.</p>
-
 <p>To cut a release candidate, there are 4 steps:</p>
 <ol>
   <li>Create a git tag for the release candidate.</li>


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@spark.apache.org
For additional commands, e-mail: commits-help@spark.apache.org