Repository: yetus Updated Branches: refs/heads/asf-site d709aeb59 -> 21be113e2
http://git-wip-us.apache.org/repos/asf/yetus/blob/21be113e/documentation/in-progress/precommit-basic/index.html ---------------------------------------------------------------------- diff --git a/documentation/in-progress/precommit-basic/index.html b/documentation/in-progress/precommit-basic/index.html index 10f9534..d7c5ca1 100644 --- a/documentation/in-progress/precommit-basic/index.html +++ b/documentation/in-progress/precommit-basic/index.html @@ -118,7 +118,7 @@ under the License. --> -<h1>test-patch</h1> +<h1 id="test-patch">test-patch</h1> <ul> <li><a href="#Purpose">Purpose</a></li> @@ -132,22 +132,22 @@ <li><a href="#Docker">Docker</a></li> </ul> -<h1>Purpose</h1> +<h1 id="purpose">Purpose</h1> -<p>As part of Apache Hadoop's commit process, all patches to the source base go through a precommit test that does some (relatively) light checking to make sure the proposed change does not break unit tests and/or passes some other prerequisites such as code formatting guidelines. This is meant as a preliminary check for committers so that the basic patch is in a known state and for contributors to know if they have followed the project's guidelines. This check, called test-patch, along with a helper program, called smart-apply-patch, may also be used by individual developers to verify a patch prior to sending to the Apache Hadoop QA systems.</p> +<p>As part of Apache Hadoop’s commit process, all patches to the source base go through a precommit test that does some (relatively) light checking to make sure the proposed change does not break unit tests and/or passes some other prerequisites such as code formatting guidelines. This is meant as a preliminary check for committers so that the basic patch is in a known state and for contributors to know if they have followed the project’s guidelines. This check, called test-patch, along with a helper program, called smart-apply-patch, may also be used by individual developers to verify a patch prior to sending to the Apache Hadoop QA systems.</p> -<p>Other projects have adopted a similar methodology after seeing great success in the Apache Hadoop model. Some have even gone as far as forking Apache Hadoop's precommit code and modifying it to meet their project's needs.</p> +<p>Other projects have adopted a similar methodology after seeing great success in the Apache Hadoop model. Some have even gone as far as forking Apache Hadoop’s precommit code and modifying it to meet their project’s needs.</p> <p>One of the key facets of Apache Yetus is to bring together all of these forks under a common code base to help software development as a whole.</p> -<h1>Pre-requisites</h1> +<h1 id="pre-requisites">Pre-requisites</h1> <p>test-patch and smart-apply-patch are written in bash for maximum portability. As such, it mostly assumes the locations of commands to be in the file path. However, in many cases, this assumption may be overridden via command line options.</p> <p>For Solaris and Solaris-like operating systems, the default location for the POSIX binaries is in /usr/xpg4/bin and the default location for the GNU binaries is /usr/gnu/bin.</p> -<h2>Base Requirements</h2> +<h2 id="base-requirements">Base Requirements</h2> <p>test-patch requires these installed components to execute:</p> @@ -163,7 +163,7 @@ as a whole.</p> <li>file command</li> </ul> -<h2>Optional Requirements</h2> +<h2 id="optional-requirements">Optional Requirements</h2> <p>Features are plug-in based and enabled either individually or collectively on the command line. From there, these are activated based upon tool availability, the languages being tested, etc. The external dependencies of plug-ins may have different licensing requirements than Apache Yetus.</p> @@ -214,26 +214,22 @@ as a whole.</p> <li><a href="https://github.com/koalaman/shellcheck";>shellcheck</a> installed, preferably 0.3.6 or higher</li> </ul> -<h1>Basic Usage</h1> +<h1 id="basic-usage">Basic Usage</h1> <p>The first step for a successful deployment is determining which features/plug-ins to enable:</p> - -<pre><code class="bash">$ test-patch.sh --list-plugins +<pre class="highlight shell"><code><span class="gp">$ </span><span class="nb">test</span>-patch.sh --list-plugins </code></pre> <p>This option will list all of the available plug-ins that are installed in the default location. From this list, the specific plug-ins can be enabled:</p> - -<pre><code class="bash">$ test-patch.sh --plugins="ant,maven,shellcheck,xml" <other options> +<pre class="highlight shell"><code><span class="gp">$ </span><span class="nb">test</span>-patch.sh --plugins<span class="o">=</span><span class="s2">"ant,maven,shellcheck,xml"</span> <other options> </code></pre> -<p>As a short-cut, every plug-in may be enabled via the special 'all' type:</p> - -<pre><code class="bash">$ test-patch.sh --plugins="all" <other options> +<p>As a short-cut, every plug-in may be enabled via the special ‘all’ type:</p> +<pre class="highlight shell"><code><span class="gp">$ </span><span class="nb">test</span>-patch.sh --plugins<span class="o">=</span><span class="s2">"all"</span> <other options> </code></pre> <p><code>--plugins</code> also allows some basic <q>arithmetic</q>:</p> - -<pre><code class="bash">$ test-patch.sh --plugins="all,-checkstyle,-findbugs" <other options> +<pre class="highlight shell"><code><span class="gp">$ </span><span class="nb">test</span>-patch.sh --plugins<span class="o">=</span><span class="s2">"all,-checkstyle,-findbugs"</span> <other options> </code></pre> <p>This will enable all plug-ins for potential usage, except for checkstyle and findbugs.</p> @@ -241,162 +237,144 @@ as a whole.</p> <p><strong>NOTE: The examples in this section will assume that the necessary <code>--plugins</code> option has been set on the command line as appropriate for your particular installation.</strong></p> <p>This command will execute basic patch testing against a patch file stored in <q>filename</q>:</p> - -<pre><code class="bash">$ cd <your repo> -$ test-patch.sh --dirty-workspace --project=projectname <filename> +<pre class="highlight shell"><code><span class="gp">$ </span><span class="nb">cd</span> <your repo> +<span class="gp">$ </span><span class="nb">test</span>-patch.sh --dirty-workspace --project<span class="o">=</span>projectname <filename> </code></pre> <p>The <code>--dirty-workspace</code> flag tells test-patch that the repository is not clean and it is ok to continue. By default, unit tests are not run since they may take a significant amount of time.</p> -<p>To do turn them on, we need to provide the --run-tests option:</p> - -<pre><code class="bash">$ cd <your repo> -$ test-patch.sh --dirty-workspace --run-tests <filename> +<p>To do turn them on, we need to provide the –run-tests option:</p> +<pre class="highlight shell"><code><span class="gp">$ </span><span class="nb">cd</span> <your repo> +<span class="gp">$ </span><span class="nb">test</span>-patch.sh --dirty-workspace --run-tests <filename> </code></pre> <p>This is the same command, but now runs the unit tests.</p> <p>A typical configuration is to have two repositories. One with the code you are working on and another, clean repository. This means you can:</p> - -<pre><code class="bash">$ cd <workrepo> -$ git diff master > /tmp/patchfile -$ cd ../<testrepo> -$ test-patch.sh --basedir=<testrepo> --resetrepo /tmp/patchfile +<pre class="highlight shell"><code><span class="gp">$ </span><span class="nb">cd</span> <workrepo> +<span class="gp">$ </span>git diff master > /tmp/patchfile +<span class="gp">$ </span><span class="nb">cd</span> ../<testrepo> +<span class="gp">$ </span><span class="nb">test</span>-patch.sh --basedir<span class="o">=</span><testrepo> --resetrepo /tmp/patchfile </code></pre> -<p>We used two new options here. --basedir sets the location of the repository to use for testing. --resetrepo tells test patch that it can go into <strong>destructive</strong> mode. Destructive mode will wipe out any changes made to that repository, so use it with care!</p> +<p>We used two new options here. –basedir sets the location of the repository to use for testing. –resetrepo tells test patch that it can go into <strong>destructive</strong> mode. Destructive mode will wipe out any changes made to that repository, so use it with care!</p> -<h1>Automation</h1> +<h1 id="automation">Automation</h1> <p>After the tests have run, there is a directory that contains all of the test-patch related artifacts. This is generally referred to as the patchprocess directory. By default, test-patch tries to make something off of /tmp to contain this content. Using the <code>--patch-dir</code> option, one can specify exactly which directory to use. This is helpful for automated precommit testing so that Jenkins or other automated workflow system knows where to look to gather up the output.</p> <p>For example:</p> - -<pre><code class="bash">$ test-patch.sh --robot --patch-dir=${WORKSPACE}/patchprocess --basedir=${WORKSPACE}/source ${WORKSPACE}/patchfile +<pre class="highlight shell"><code><span class="gp">$ </span><span class="nb">test</span>-patch.sh --robot --patch-dir<span class="o">=</span><span class="k">${</span><span class="nv">WORKSPACE</span><span class="k">}</span>/patchprocess --basedir<span class="o">=</span><span class="k">${</span><span class="nv">WORKSPACE</span><span class="k">}</span>/source <span class="k">${</span><span class="nv">WORKSPACE</span><span class="k">}</span>/patchfile </code></pre> -<p>... will trigger test-patch to run in fully automated mode, using ${WORKSPACE}/patchprocess as its scratch space, ${WORKSPACE}/source as the source repository, and ${WORKSPACE}/patchfile as the name of the patch to test against. This will always run the unit tests, write answers back to bug systems, remove old, stopped/exited Docker images and containers after 24 hours, forcibly use --resetrepo, and more. The --build-url option is also useful when running in --robot mode so that emails and such +<p>… will trigger test-patch to run in fully automated mode, using ${WORKSPACE}/patchprocess as its scratch space, ${WORKSPACE}/source as the source repository, and ${WORKSPACE}/patchfile as the name of the patch to test against. This will always run the unit tests, write answers back to bug systems, remove old, stopped/exited Docker images and containers after 24 hours, forcibly use –resetrepo, and more. The –build-url option is also useful when running in –robot mode so that emails and such have a location to look at the output artifacts:</p> - -<pre><code class="bash">$ test-patch.sh --robot --build-url=http://server.example.name:80/${buildnumber}/ +<pre class="highlight shell"><code><span class="gp">$ </span><span class="nb">test</span>-patch.sh --robot --build-url<span class="o">=</span>http://server.example.name:80/<span class="k">${</span><span class="nv">buildnumber</span><span class="k">}</span>/ </code></pre> <p>Some plug-ins such as Maven have special handling if there are multiple executions of test-patch happening at once. It is very common when using automation systems to have multiple runs on the same host. In order to assist these plug-ins, an instance identifier may be provided:</p> - -<pre><code class="bash">$ test-patch.sh --robot --instance=1 +<pre class="highlight shell"><code><span class="gp">$ </span><span class="nb">test</span>-patch.sh --robot --instance<span class="o">=</span>1 </code></pre> -<p>If --robot is specified without an instance, a random number is generated and used.</p> - -<p>There is some special handling if Jenkins is actually your automation tool. Instead of using --robot, use --jenkins:</p> +<p>If –robot is specified without an instance, a random number is generated and used.</p> -<pre><code class="bash">$ test-patch.sh --jenkins --patch-dir=${WORKSPACE}/patchprocess --basedir=${WORKSPACE}/source ${WORKSPACE}/patchfile +<p>There is some special handling if Jenkins is actually your automation tool. Instead of using –robot, use –jenkins:</p> +<pre class="highlight shell"><code><span class="gp">$ </span><span class="nb">test</span>-patch.sh --jenkins --patch-dir<span class="o">=</span><span class="k">${</span><span class="nv">WORKSPACE</span><span class="k">}</span>/patchprocess --basedir<span class="o">=</span><span class="k">${</span><span class="nv">WORKSPACE</span><span class="k">}</span>/source <span class="k">${</span><span class="nv">WORKSPACE</span><span class="k">}</span>/patchfile </code></pre> -<p>This will enable --robot, set the --build-url option from the ${BUILD_URL} environment variable, and the instance identifier is set to the ${EXECUTOR_NUMBER}.</p> +<p>This will enable –robot, set the –build-url option from the ${BUILD_URL} environment variable, and the instance identifier is set to the ${EXECUTOR_NUMBER}.</p> -<p>If stuck containers are a problem, a more aggressive robot may be enabled with the --sentinel option. This option enables killing containers that have been running for over 24 hours as well.</p> +<p>If stuck containers are a problem, a more aggressive robot may be enabled with the –sentinel option. This option enables killing containers that have been running for over 24 hours as well.</p> -<h1>Build Tool</h1> +<h1 id="build-tool">Build Tool</h1> <p>Out of the box, test-patch is built to use maven. But what if the project is built using something else, such as ant?</p> - -<pre><code class="bash">$ test-patch.sh (other options) --build-tool=ant +<pre class="highlight shell"><code><span class="gp">$ </span><span class="nb">test</span>-patch.sh <span class="o">(</span>other options<span class="o">)</span> --build-tool<span class="o">=</span>ant </code></pre> <p>will tell test-patch to use ant instead of maven to drive the project.</p> -<h1>Providing Patch Files</h1> +<h1 id="providing-patch-files">Providing Patch Files</h1> -<h2>JIRA</h2> +<h2 id="jira">JIRA</h2> -<p>It is a fairly common practice within the Apache community to use Apache's JIRA instance to store potential patches. As a result, test-patch supports providing just a JIRA issue number. test-patch will find the <em>last</em> attachment, download it, then process it.</p> +<p>It is a fairly common practice within the Apache community to use Apache’s JIRA instance to store potential patches. As a result, test-patch supports providing just a JIRA issue number. test-patch will find the <em>last</em> attachment, download it, then process it.</p> <p>For example:</p> - -<pre><code class="bash">$ test-patch.sh (other options) HADOOP-9905 +<pre class="highlight shell"><code><span class="gp">$ </span><span class="nb">test</span>-patch.sh <span class="o">(</span>other options<span class="o">)</span> HADOOP-9905 </code></pre> -<p>... will process the patch file associated with this JIRA issue.</p> +<p>… will process the patch file associated with this JIRA issue.</p> <p>If the Apache JIRA system is not in use, then override options may be provided on the command line to point to a different JIRA instance.</p> - -<pre><code class="bash">$ test-patch.sh --jira-issue-re='^PROJECT-[0-9]+$' --jira-base-url='https://example.com/jira' PROJECT-90 +<pre class="highlight shell"><code><span class="gp">$ </span><span class="nb">test</span>-patch.sh --jira-issue-re<span class="o">=</span><span class="s1">'^PROJECT-[0-9]+$'</span> --jira-base-url<span class="o">=</span><span class="s1">'https://example.com/jira'</span> PROJECT-90 </code></pre> -<p>... will process the patch file attached to PROJECT-90 on the JIRA instance located on the example.com server.</p> +<p>… will process the patch file attached to PROJECT-90 on the JIRA instance located on the example.com server.</p> -<h2>GITHUB</h2> +<h2 id="github">GITHUB</h2> <p>test-patch has some basic support for Github. test-patch supports many forms of providing pull requests to work on:</p> - -<pre><code class="bash">$ test-patch.sh --github-repo=apache/pig 99 +<pre class="highlight shell"><code><span class="gp">$ </span><span class="nb">test</span>-patch.sh --github-repo<span class="o">=</span>apache/pig 99 </code></pre> <p>or</p> - -<pre><code class="bash">$ test-patch.sh https://github.com/apache/pig/pulls/99 +<pre class="highlight shell"><code><span class="gp">$ </span><span class="nb">test</span>-patch.sh https://github.com/apache/pig/pulls/99 </code></pre> <p>or</p> - -<pre><code class="bash">$ test-patch.sh https://github.com/apache/pig/pulls/99.patch +<pre class="highlight shell"><code><span class="gp">$ </span><span class="nb">test</span>-patch.sh https://github.com/apache/pig/pulls/99.patch </code></pre> -<p>... will process PR #99 on the apache/pig repo.</p> +<p>… will process PR #99 on the apache/pig repo.</p> -<h2>Generic URLs</h2> +<h2 id="generic-urls">Generic URLs</h2> <p>Luckily, test-patch supports provide ways to provide unified diffs via URLs.</p> <p>For example:</p> - -<pre><code class="bash">$ test-patch.sh (other options) https://example.com/webserver/file.patch +<pre class="highlight shell"><code><span class="gp">$ </span><span class="nb">test</span>-patch.sh <span class="o">(</span>other options<span class="o">)</span> https://example.com/webserver/file.patch </code></pre> -<p>... will download and process the file.patch from the example.com webserver.</p> +<p>… will download and process the file.patch from the example.com webserver.</p> -<h1>Project-specific Capabilities</h1> +<h1 id="project-specific-capabilities">Project-specific Capabilities</h1> <p>Due to the extensible nature of the system, test-patch allows for projects to define project-specific rules which we call personalities. (How to build those rules is covered elsewhere.) There are two ways to specify which personality to use:</p> -<h2>Direct Method</h2> - -<pre><code class="bash">$ test-patch.sh (other options) --personality=(filename) +<h2 id="direct-method">Direct Method</h2> +<pre class="highlight shell"><code><span class="gp">$ </span><span class="nb">test</span>-patch.sh <span class="o">(</span>other options<span class="o">)</span> --personality<span class="o">=(</span>filename<span class="o">)</span> </code></pre> <p>This tells test-patch to use the personality in the given file.</p> -<h2>Project Method</h2> +<h2 id="project-method">Project Method</h2> <p>However, test-patch can detect if it is a personality that is in its <q>personality</q> directory based upon the project name:</p> - -<pre><code class="bash">$ test-patch.sh (other options) --project=(project) +<pre class="highlight shell"><code><span class="gp">$ </span><span class="nb">test</span>-patch.sh <span class="o">(</span>other options<span class="o">)</span> --project<span class="o">=(</span>project<span class="o">)</span> </code></pre> -<h1>MultiJDK</h1> +<h1 id="multijdk">MultiJDK</h1> -<p>For many projects, it is useful to test Java code against multiple versions of JDKs at the same time. test-patch can do this with the --multijdkdirs option:</p> - -<pre><code class="bash">$ test-patch.sh (other options) --multijdkdirs="/j/d/k/1,/j/d/k/2" +<p>For many projects, it is useful to test Java code against multiple versions of JDKs at the same time. test-patch can do this with the –multijdkdirs option:</p> +<pre class="highlight shell"><code><span class="gp">$ </span><span class="nb">test</span>-patch.sh <span class="o">(</span>other options<span class="o">)</span> --multijdkdirs<span class="o">=</span><span class="s2">"/j/d/k/1,/j/d/k/2"</span> </code></pre> -<p>Not all Java tests support this mode, but those that do will now run their tests with all of the given versions of Java consecutively (e.g., javac--the Java compliation test). Tests that do not support MultiJDK mode (e.g., checkstyle, mvn install) will use JAVA_HOME.</p> +<p>Not all Java tests support this mode, but those that do will now run their tests with all of the given versions of Java consecutively (e.g., javac–the Java compliation test). Tests that do not support MultiJDK mode (e.g., checkstyle, mvn install) will use JAVA_HOME.</p> <p>NOTE: JAVA_HOME is always appended to the list of JDKs in MultiJDK mode. If JAVA_HOME is in the list, it will be moved to the end.</p> -<h1>Docker</h1> +<h1 id="docker">Docker</h1> <p>test-patch also has a mode to utilize Docker:</p> - -<pre><code class="bash">$ test-patch.sh (other options) --docker +<pre class="highlight shell"><code><span class="gp">$ </span><span class="nb">test</span>-patch.sh <span class="o">(</span>other options<span class="o">)</span> --docker </code></pre> <p>This will do some preliminary setup and then re-execute itself inside a Docker container. For more information on how to provide a custom Dockerfile, see the advanced guide.</p> -<h2>In Closing</h2> +<h2 id="in-closing">In Closing</h2> -<p>test-patch has many other features and command line options for the basic user. Many of these are self-explanatory. To see the list of options, run test-patch.sh without any options or with --help.</p> +<p>test-patch has many other features and command line options for the basic user. Many of these are self-explanatory. To see the list of options, run test-patch.sh without any options or with –help.</p> </div> <div class="container"> http://git-wip-us.apache.org/repos/asf/yetus/blob/21be113e/documentation/in-progress/precommit-bugsystems/index.html ---------------------------------------------------------------------- diff --git a/documentation/in-progress/precommit-bugsystems/index.html b/documentation/in-progress/precommit-bugsystems/index.html index 6fbf025..aefa7c2 100644 --- a/documentation/in-progress/precommit-bugsystems/index.html +++ b/documentation/in-progress/precommit-bugsystems/index.html @@ -118,11 +118,10 @@ under the License. --> -<h1>Bug System Support</h1> +<h1 id="bug-system-support">Bug System Support</h1> <p>test-patch has the ability to support multiple bug systems. Bug tools have some extra hooks to fetch patches, line-level reporting, and posting a final report. Every bug system plug-in must have one line in order to be recognized:</p> - -<pre><code class="bash">add_bugsystem <pluginname> +<pre class="highlight shell"><code>add_bugsystem <pluginname> </code></pre> <ul> @@ -144,7 +143,7 @@ <li><p>pluginname_write_comment</p> <ul> -<li>Given text input, write this output to the bug system as a comment. NOTE: It is the bug system's responsibility to format appropriately.</li> +<li>Given text input, write this output to the bug system as a comment. NOTE: It is the bug system’s responsibility to format appropriately.</li> </ul></li> <li><p>pluginname_linecomments</p> @@ -158,18 +157,17 @@ </ul></li> </ul> -<h1>Bugzilla Specific</h1> - -<p>Currently, Bugzilla support is read-only. To use it, the Bug ID must be preferenced with 'BZ:'. For example:</p> +<h1 id="bugzilla-specific">Bugzilla Specific</h1> -<pre><code class="bash">$ test-patch.sh (other options) BZ:4 +<p>Currently, Bugzilla support is read-only. To use it, the Bug ID must be preferenced with ‘BZ:’. For example:</p> +<pre class="highlight shell"><code><span class="gp">$ </span><span class="nb">test</span>-patch.sh <span class="o">(</span>other options<span class="o">)</span> BZ:4 </code></pre> -<p>... will pull down Bugzilla ID #4.</p> +<p>… will pull down Bugzilla ID #4.</p> -<p>Using the <code>--bugzilla-base-url</code> on the command line or BUGZILLA_BASE_URL in a project's personality will define the location of the Bugzilla instance. By default, it is <a href="https://bz.apache.org/bugzilla";>https://bz.apache.org/bugzilla</a> .</p> +<p>Using the <code>--bugzilla-base-url</code> on the command line or BUGZILLA_BASE_URL in a project’s personality will define the location of the Bugzilla instance. By default, it is <a href="https://bz.apache.org/bugzilla";>https://bz.apache.org/bugzilla</a> .</p> -<h1>GitHub Specific</h1> +<h1 id="github-specific">GitHub Specific</h1> <p>GitHub supports the full range of functionality, including putting comments on individual lines. Be aware, however, that test-patch.sh will require that GitHub PRs be fully rebased (i.e., a single commit) in many circumstances.</p> @@ -186,7 +184,7 @@ <p>Pull requests that are made off of a specific branch will switch the test repo to that branch, if permitted. If the pull request references a JIRA issue that matches the given JIRA issue regexp in the Subject, the JIRA plug-in will also be invoked as needed.</p> -<h1>JIRA Specific</h1> +<h1 id="jira-specific">JIRA Specific</h1> <p>JIRA support allows both patch downloads and summary writes. It also supports branch detection-based upon the name of the attached patch file.</p> http://git-wip-us.apache.org/repos/asf/yetus/blob/21be113e/documentation/in-progress/precommit-buildtools/index.html ---------------------------------------------------------------------- diff --git a/documentation/in-progress/precommit-buildtools/index.html b/documentation/in-progress/precommit-buildtools/index.html index f5a9473..b5686d1 100644 --- a/documentation/in-progress/precommit-buildtools/index.html +++ b/documentation/in-progress/precommit-buildtools/index.html @@ -118,20 +118,19 @@ under the License. --> -<h1>Build Tool Support</h1> +<h1 id="build-tool-support">Build Tool Support</h1> <p>test-patch has the ability to support multiple build tools. Build tool plug-ins have some extra hooks to do source and object maintenance at key points. Every build tool plug-in must have one line in order to be recognized:</p> - -<pre><code class="bash">add_build_tool <pluginname> +<pre class="highlight shell"><code>add_build_tool <pluginname> </code></pre> -<h1>Global Variables</h1> +<h1 id="global-variables">Global Variables</h1> <ul> <li><p>BUILDTOOLCWD</p> <ul> -<li>This variable determines where the build tool's command (as returned by pluginname_executor) should actually execute. It should be one of three values:</li> +<li>This variable determines where the build tool’s command (as returned by pluginname_executor) should actually execute. It should be one of three values:</li> <li>basedir - always execute at the root of the source tree</li> <li>module - switch to the directory as given by the module being processed</li> <li>/(path) - change to the directory as given by this absolute path. If the path does not exist, it will be created.</li> @@ -146,8 +145,8 @@ </ul> <p>This allows for custom directories to be created and used as necessary.</p> - -<p>The default is module.</p> +<pre class="highlight plaintext"><code>The default is module. +</code></pre> <ul> <li><p>UNSUPPORTED_TEST</p> @@ -159,7 +158,7 @@ <p>For example, the gradle build tool does not have a standard way to execute checkstyle. So when checkstyle is requested, gradle_modules_worker sets UNSUPPORTED_TEST to true and returns out of the routine.</p> -<h1>Required Functions</h1> +<h1 id="required-functions">Required Functions</h1> <ul> <li><p>pluginname_buildfile</p> @@ -175,7 +174,7 @@ <li><p>pluginname_modules_worker</p> <ul> -<li>Input is the branch and the test being run. This should call <code>modules_workers</code> with the generic parts to run that test on the build system. For example, if it is convention to use 'test' to trigger 'unit' tests, then <code>module_workers</code> should be called with 'test' appended onto its normal parameters.</li> +<li>Input is the branch and the test being run. This should call <code>modules_workers</code> with the generic parts to run that test on the build system. For example, if it is convention to use ‘test’ to trigger 'unit’ tests, then <code>module_workers</code> should be called with 'test’ appended onto its normal parameters.</li> </ul></li> <li><p>pluginname_builtin_personality_modules</p> @@ -189,7 +188,7 @@ </ul></li> </ul> -<h1>Optional Functions</h1> +<h1 id="optional-functions">Optional Functions</h1> <ul> <li><p>pluginname_postapply_install</p> @@ -231,45 +230,45 @@ <p><strong>WARNING</strong>: Be aware that directories that do not exist MAY be created by root by Docker itself under certain conditions. It is HIGHLY recommend that <code>pluginname_initialize</code> be used to create the necessary directories prior to be used in the <code>docker run</code> command.</p></li> </ul> -<h1>Ant Specific</h1> +<h1 id="ant-specific">Ant Specific</h1> -<h2>Command Arguments</h2> +<h2 id="command-arguments">Command Arguments</h2> <p>test-patch always passes -noinput to Ant. This forces ant to be non-interactive.</p> -<h2>Docker Mode</h2> +<h2 id="docker-mode">Docker Mode</h2> <p>In Docker mode, the <code>${HOME}/.ivy2</code> directory is shared amongst all invocations.</p> -<h1>autoconf Specific</h1> +<h1 id="autoconf-specific">autoconf Specific</h1> <p>autoconf requires make to be enabled. autoreconf is always used to rebuild the configure scripte.</p> -<h2>Command Arguments</h2> +<h2 id="command-arguments">Command Arguments</h2> <p>autoconf will always run configure with prefix set to a directory in the patch processing directory. To configure other flags, set the AUTCONF_CONF_FLAGS environment variable.</p> -<h1>CMAKE Specific</h1> +<h1 id="cmake-specific">CMAKE Specific</h1> -<p>By default, cmake will create a 'build' directory and perform all work there. This may be changed either on the command line or via a personality setting. cmake requires make to be enabled.</p> +<p>By default, cmake will create a 'build’ directory and perform all work there. This may be changed either on the command line or via a personality setting. cmake requires make to be enabled.</p> -<h1>Gradle Specific</h1> +<h1 id="gradle-specific">Gradle Specific</h1> <p>The gradle plug-in always rebuilds the gradlew file and uses gradlew as the method to execute commands.</p> <p>In Docker mode, the <code>${HOME}/.gradle</code> directory is shared amongst all invocations.</p> -<h1>Make Specific</h1> +<h1 id="make-specific">Make Specific</h1> <p>No notes.</p> -<h1>Maven Specific</h1> +<h1 id="maven-specific">Maven Specific</h1> -<h2>Command Arguments</h2> +<h2 id="command-arguments">Command Arguments</h2> -<p>test-patch always passes --batch-mode to maven to force it into non-interactive mode. Additionally, some tests will also force -fae in order to get all of messages/errors during that mode. Some tests are executed with -DskipTests. Additional arguments should be handled via the personality.</p> +<p>test-patch always passes –batch-mode to maven to force it into non-interactive mode. Additionally, some tests will also force -fae in order to get all of messages/errors during that mode. Some tests are executed with -DskipTests. Additional arguments should be handled via the personality.</p> -<h2>Per-instance Repositories</h2> +<h2 id="per-instance-repositories">Per-instance Repositories</h2> <p>Under many common configurations, maven (as of 3.3.3 and lower) may not properly handle being executed by multiple processes simultaneously, especially given that some tests require the <code>mvn install</code> command to be used.</p> @@ -279,21 +278,19 @@ <p>The location of the <code>settings.xml</code> may be changed via the <code>--mvn-settings</code> option.</p> -<h2>Docker Mode</h2> +<h2 id="docker-mode">Docker Mode</h2> <p>In Docker mode, <code>${HOME}/.m2</code> is shared amongst all invocations. If <code>--mvn-custom-repos</code> is used, all of <code>--mvn-custom-repos-dir</code> is shared with all invocations. The per-instance directory will be calculated and configured after Docker has launched.</p> -<h2>Test Profile</h2> +<h2 id="test-profile">Test Profile</h2> <p>By default, test-patch will pass -Ptest-patch to Maven. This will allow you to configure special actions that should only happen when running underneath test-patch.</p> -<h2>Custom Maven Tests</h2> +<h2 id="custom-maven-tests">Custom Maven Tests</h2> -<ul> -<li>Maven will trigger a maven install as part of the precompile.</li> -<li>Maven will test eclipse integration as part of the postcompile.</li> -<li>If src/site is modified, maven site tests are executed.</li> -</ul> +<p>Maven will test eclipse and site if maven is being used as the build tool and appropriate files trigger them.</p> + +<p>Maven will trigger add a maven install test when the <code>maven_add_install</code> function has been used and the related tests are requierd. Plug-ins that need to run maven before MUST call it as part of their respective initialize functions, otherwise maven may fail unexpectedly. All Yetus provided plug-ins that require maven will trigger the maven install functionality.</p> </div> <div class="container"> http://git-wip-us.apache.org/repos/asf/yetus/blob/21be113e/documentation/in-progress/precommit-glossary/index.html ---------------------------------------------------------------------- diff --git a/documentation/in-progress/precommit-glossary/index.html b/documentation/in-progress/precommit-glossary/index.html index 195c939..596ad4c 100644 --- a/documentation/in-progress/precommit-glossary/index.html +++ b/documentation/in-progress/precommit-glossary/index.html @@ -118,11 +118,11 @@ under the License. --> -<h1>Glossary</h1> +<h1 id="glossary">Glossary</h1> -<h2>Generic/outside definitions:</h2> +<h2 id="generic-outside-definitions">Generic/outside definitions:</h2> -<p>Apache's <a href="https://community.apache.org/contributors/";>new contributor documentation</a> and Maven's <a href="https://maven.apache.org/glossary.html";>glossary</a> are great places to start if you are new to Apache or Maven.</p> +<p>Apache’s <a href="https://community.apache.org/contributors/";>new contributor documentation</a> and Maven’s <a href="https://maven.apache.org/glossary.html";>glossary</a> are great places to start if you are new to Apache or Maven.</p> <ul> <li>Module</li> @@ -130,13 +130,13 @@ <p>Almost the same meaning as <q>sub-project</q> on Maven.</p> -<h2>test-patch specific</h2> +<h2 id="test-patch-specific">test-patch specific</h2> <ul> <li>Personality</li> </ul> -<p>A chunk of shell code that tells test-patch this particular project's needs and special requirements</p> +<p>A chunk of shell code that tells test-patch this particular project’s needs and special requirements</p> <ul> <li>Plug-ins</li> http://git-wip-us.apache.org/repos/asf/yetus/blob/21be113e/documentation/in-progress/precommit-patchnames/index.html ---------------------------------------------------------------------- diff --git a/documentation/in-progress/precommit-patchnames/index.html b/documentation/in-progress/precommit-patchnames/index.html index 7ce589d..8909622 100644 --- a/documentation/in-progress/precommit-patchnames/index.html +++ b/documentation/in-progress/precommit-patchnames/index.html @@ -121,10 +121,10 @@ <p>We use Apache Yetus to process your patch. It supports the following patterns and procedures for patch file names:</p> -<h2>JIRA</h2> +<h2 id="jira">JIRA</h2> <p>If JIRA support is configured, attach the patch to the given ISSUE and -click 'Submit Patch'. The patch file should be named one of:</p> +click ‘Submit Patch’. The patch file should be named one of:</p> <ul> <li>ISSUE.patch</li> @@ -143,9 +143,9 @@ click 'Submit Patch'. The patch file should be named one of:</p> <li>###: revision of the patch (e.g. 00 or 01)</li> </ul> -<h2>Github</h2> +<h2 id="github">Github</h2> -<p>If Github support is also configured, a comment that contains a link to a Pull Request's +<p>If Github support is also configured, a comment that contains a link to a Pull Request’s patch file (e.g., <a href="https://github.com/user/repo/pull/1.patch";>https://github.com/user/repo/pull/1.patch</a>) will pull the patch from the given Github PR.</p> http://git-wip-us.apache.org/repos/asf/yetus/blob/21be113e/documentation/in-progress/precommit-smart-apply-patch/index.html ---------------------------------------------------------------------- diff --git a/documentation/in-progress/precommit-smart-apply-patch/index.html b/documentation/in-progress/precommit-smart-apply-patch/index.html index 6f91ae3..05db324 100644 --- a/documentation/in-progress/precommit-smart-apply-patch/index.html +++ b/documentation/in-progress/precommit-smart-apply-patch/index.html @@ -118,27 +118,24 @@ under the License. --> -<h1>smart-apply-patch</h1> +<h1 id="smart-apply-patch">smart-apply-patch</h1> <p><code>smart-apply-patch</code> is a command to help apply patches easily. It uses the same plug-ins and many of the same options as test-patch. This means that it can, for example, fetch patches from JIRA and apply them to a local source tree.</p> -<h1>Usage</h1> +<h1 id="usage">Usage</h1> <p>Its simpliest form is used when a patch is stored in a local file:</p> - -<pre><code class="bash">$ smart-apply-patch patch +<pre class="highlight shell"><code><span class="gp">$ </span>smart-apply-patch patch </code></pre> <p>This will cause the command to run through various ways to verify and then apply the patch to the current repo, including deducing a patch level.</p> <p>Perhaps you just want to see if the patch even applies without changing your local repo. The <code>--dry-run</code> option will just test for applicability:</p> - -<pre><code class="bash">$ smart-apply-patch --dry-run patch +<pre class="highlight shell"><code><span class="gp">$ </span>smart-apply-patch --dry-run patch </code></pre> <p>For committers of projects, there is a special mode:</p> - -<pre><code class="bash">$ smart-apply-patch --committer patch +<pre class="highlight shell"><code><span class="gp">$ </span>smart-apply-patch --committer patch </code></pre> <p>that in addition to applying the patch will also attempt to:</p> http://git-wip-us.apache.org/repos/asf/yetus/blob/21be113e/documentation/in-progress/precommit-testformats/index.html ---------------------------------------------------------------------- diff --git a/documentation/in-progress/precommit-testformats/index.html b/documentation/in-progress/precommit-testformats/index.html index 1b3cd83..67bca42 100644 --- a/documentation/in-progress/precommit-testformats/index.html +++ b/documentation/in-progress/precommit-testformats/index.html @@ -118,11 +118,10 @@ under the License. --> -<h1>Test Format Support</h1> +<h1 id="test-format-support">Test Format Support</h1> <p>test-patch has the ability to support multiple test formats. Test formats have some extra hooks to process the output of test tools and write the results to some tables. Every test format plug-in must have one line in order to be recognized:</p> - -<pre><code class="bash">add_test_format <pluginname> +<pre class="highlight shell"><code>add_test_format <pluginname> </code></pre> <ul> http://git-wip-us.apache.org/repos/asf/yetus/blob/21be113e/documentation/in-progress/releasedocmaker/index.html ---------------------------------------------------------------------- diff --git a/documentation/in-progress/releasedocmaker/index.html b/documentation/in-progress/releasedocmaker/index.html index 9866119..bec64a0 100644 --- a/documentation/in-progress/releasedocmaker/index.html +++ b/documentation/in-progress/releasedocmaker/index.html @@ -118,7 +118,7 @@ under the License. --> -<h1>releasedocmaker</h1> +<h1 id="releasedocmaker">releasedocmaker</h1> <ul> <li><a href="#Purpose">Purpose</a></li> @@ -130,7 +130,7 @@ <li><a href="#Index_Mode">Index Mode</a></li> </ul> -<h1>Purpose</h1> +<h1 id="purpose">Purpose</h1> <p>Building changelog information in a form that is human digestible but still containing as much useful information is difficult. Many attempts over the years have resulted in a variety of methods that projects use to solve this problem:</p> @@ -142,13 +142,12 @@ <p>All of these methods have their pros and cons. Some have issues with accuracy. Some have issues with lack of details. None of these methods seem to cover all of the needs of many projects and are full of potential pitfalls.</p> -<p>In order to solve these problems, releasedocmaker was written to automatically generate a changelog and release notes by querying Apache's JIRA instance.</p> +<p>In order to solve these problems, releasedocmaker was written to automatically generate a changelog and release notes by querying Apache’s JIRA instance.</p> -<h1>Basic Usage</h1> +<h1 id="basic-usage">Basic Usage</h1> <p>Minimally, the name of the JIRA project and a version registered in JIRA must be provided:</p> - -<pre><code class="bash">$ releasedocmaker.py --project (project) --version (version) +<pre class="highlight shell"><code><span class="gp">$ </span>releasedocmaker.py --project <span class="o">(</span>project<span class="o">)</span> --version <span class="o">(</span>version<span class="o">)</span> </code></pre> <p>This will query Apache JIRA, generating two files in a directory named after the given version in an extended markdown format which can be processed by both mvn site and GitHub.</p> @@ -165,67 +164,60 @@ <p>If your JIRA project supports the release note field, this will contain any JIRA mentioned in the CHANGES log that is either an incompatible change or has a release note associated with it. If your JIRA project does not support the release notes field, this will be the description field.</p> -<p>For example, to build the release documentation for HBase v1.2.0...</p> - -<pre><code class="bash">$ releasedocmaker.py --project HBASE --version 1.2.0 +<p>For example, to build the release documentation for HBase v1.2.0…</p> +<pre class="highlight shell"><code><span class="gp">$ </span>releasedocmaker.py --project HBASE --version 1.2.0 </code></pre> -<p>... will create a 1.2.0 directory and inside that directory will be CHANGES.1.2.0.md and RELEASENOTES.1.2.0.md .</p> +<p>… will create a 1.2.0 directory and inside that directory will be CHANGES.1.2.0.md and RELEASENOTES.1.2.0.md .</p> <p>By default, release notes are expected to be in plain text. However, you can write them in markdown if you include a header at the top of your release note:</p> - -<pre><code class="xml"><!-- markdown --> +<pre class="highlight xml"><code><span class="c"><!-- markdown --></span> remaining text </code></pre> -<h1>Changing the Header</h1> +<h1 id="changing-the-header">Changing the Header</h1> <p>By default, it will use a header that matches the project name. But that is kind of ugly and the case may be wrong. Luckily, the title can be changed:</p> - -<pre><code class="bash">$ releasedocmaker.py --project HBASE --version 1.2.0 --projecttitle "Apache HBase" +<pre class="highlight shell"><code><span class="gp">$ </span>releasedocmaker.py --project HBASE --version 1.2.0 --projecttitle <span class="s2">"Apache HBase"</span> </code></pre> <p>Now instead of <q>HBASE</q>, it will use <q>Apache HBASE</q> for some titles and headers.</p> -<h1>Multiple Versions</h1> +<h1 id="multiple-versions">Multiple Versions</h1> <p>The script can also generate multiple versions at once, by</p> - -<pre><code class="bash">$ releasedocmaker.py --project HBASE --version 1.0.0 --version 1.2.0 +<pre class="highlight shell"><code><span class="gp">$ </span>releasedocmaker.py --project HBASE --version 1.0.0 --version 1.2.0 </code></pre> <p>This will create the files for versions 1.0.0 and versions 1.2.0 in their own directories.</p> <p>But what if the version numbers are not known? releasedocmaker can also generate version data based upon ranges:</p> - -<pre><code class="bash">$ releasedocmaker.py --project HBASE --version 1.0.0 --version 1.2.0 --range +<pre class="highlight shell"><code><span class="gp">$ </span>releasedocmaker.py --project HBASE --version 1.0.0 --version 1.2.0 --range </code></pre> <p>In this form, releasedocmaker will query JIRA, discover all versions that alphabetically appear to be between 1.0.0 and 1.2.0, inclusive, and generate all of the relative release documents. This is especially useful when bootstrapping an existing project.</p> -<h1>Unreleased Dates</h1> +<h1 id="unreleased-dates">Unreleased Dates</h1> <p>For released versions, releasedocmaker will pull the date of the release from JIRA. However, for unreleased versions it marks the release as <q>Unreleased</q>. This can be inconvenient when actually building a release and wanting to include it inside the source package.</p> -<p>The --usetoday option can be used to signify that instead of using Unreleased, releasedocmaker should use today's date.</p> - -<pre><code class="bash">$ releasedocmaker.py --project HBASE --version 1.0.0 --usetoday +<p>The –usetoday option can be used to signify that instead of using Unreleased, releasedocmaker should use today’s date.</p> +<pre class="highlight shell"><code><span class="gp">$ </span>releasedocmaker.py --project HBASE --version 1.0.0 --usetoday </code></pre> -<p>After using this option and release, don't forget to change JIRA's release date to match!</p> +<p>After using this option and release, don’t forget to change JIRA’s release date to match!</p> -<h1>Lint Mode</h1> +<h1 id="lint-mode">Lint Mode</h1> <p>In order to ensure proper formatting while using mvn site, releasedocmaker puts in periods (.) for fields that are empty or unassigned. This can be unsightly and not proper for any given project. There are also other things, such as missing release notes for incompatible changes, that are less than desirable.</p> -<p>In order to help release managers from having to scan through potentially large documents, releasedocmaker features a lint mode, triggered via --lint:</p> - -<pre><code class="bash">$ releasedocmaker.py --project HBASE --version 1.0.0 --lint +<p>In order to help release managers from having to scan through potentially large documents, releasedocmaker features a lint mode, triggered via –lint:</p> +<pre class="highlight shell"><code><span class="gp">$ </span>releasedocmaker.py --project HBASE --version 1.0.0 --lint </code></pre> <p>This will do the normal JIRA querying, looking for items it considers problematic. It will print the information to the screen and then exit with either success or failure, depending upon if any issues were discovered.</p> -<h1>Index Mode</h1> +<h1 id="index-mode">Index Mode</h1> <p>There is basic support for an autoindexer. It will create two files that contain links to all directories that have a major.minor.micro-style version numbering system, where all fields are numeric.</p> http://git-wip-us.apache.org/repos/asf/yetus/blob/21be113e/downloads/index.html ---------------------------------------------------------------------- diff --git a/downloads/index.html b/downloads/index.html index d062521..35bc165 100644 --- a/downloads/index.html +++ b/downloads/index.html @@ -118,7 +118,7 @@ under the License. --> -<h1>Apache Yetus Downloads</h1> +<h1 id="apache-yetus-downloads">Apache Yetus Downloads</h1> <p>The Apache Yetus project publishes a single source artifact per release for all of our components as well as a convenience artifact of binaries and documentation for immediate use. You @@ -128,7 +128,7 @@ using the <a href="https://dist.apache.org/repos/dist/release/yetus/KEYS";>KEYS f <p>In addition to the artifacts below, we publish convenience artifacts in some third-party repositories (e.g. Maven Central).</p> -<h2>Releases</h2> +<h2 id="releases">Releases</h2> <ul> <li>0.1.0 http://git-wip-us.apache.org/repos/asf/yetus/blob/21be113e/index.html ---------------------------------------------------------------------- diff --git a/index.html b/index.html index 6f511d7..1df202c 100644 --- a/index.html +++ b/index.html @@ -122,7 +122,7 @@ <div class="jumbotron"> <h1>Apache Yetus</h1> <div> - <p>... is a collection of libraries and tools that enable contribution and release processes for software projects.</p> + <p>… is a collection of libraries and tools that enable contribution and release processes for software projects.</p> </div> </div> </div> http://git-wip-us.apache.org/repos/asf/yetus/blob/21be113e/mailinglists/index.html ---------------------------------------------------------------------- diff --git a/mailinglists/index.html b/mailinglists/index.html index b0b510b..e02ab23 100644 --- a/mailinglists/index.html +++ b/mailinglists/index.html @@ -118,7 +118,7 @@ under the License. --> -<h1>Community</h1> +<h1 id="community">Community</h1> <div class="row-fluid"> <div class="col-lg-6">
