Reply-To: dev@yetus.apache.org Delivered-To: mailing list commits@yetus.apache.org Received: (qmail 27224 invoked by uid 99); 31 Aug 2018 17:31:41 -0000 Received: from git1-us-west.apache.org (HELO git1-us-west.apache.org) (140.211.11.23) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 31 Aug 2018 17:31:41 +0000 Received: by git1-us-west.apache.org (ASF Mail Server at git1-us-west.apache.org, from userid 33) id DC4EBE1194; Fri, 31 Aug 2018 17:31:40 +0000 (UTC) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: aw@apache.org To: commits@yetus.apache.org Date: Fri, 31 Aug 2018 17:31:58 -0000 Message-Id: <704574b703e6481f86d36fb3718a0429@git.apache.org> In-Reply-To: <73d85d29889f4f14bfeb6959c83380c4@git.apache.org> References: <73d85d29889f4f14bfeb6959c83380c4@git.apache.org> X-Mailer: ASF-Git Admin Mailer Subject: [19/37] yetus git commit: git hash 293c23e303c19f33ebd745679fa842486ec9d9b7 http://git-wip-us.apache.org/repos/asf/yetus/blob/4a356e40/documentation/0.5.0/precommit-basic/index.html ---------------------------------------------------------------------- diff --git a/documentation/0.5.0/precommit-basic/index.html b/documentation/0.5.0/precommit-basic/index.html deleted file mode 100644 index 70c6de6..0000000 --- a/documentation/0.5.0/precommit-basic/index.html +++ /dev/null @@ -1,385 +0,0 @@ - - - - - - Apache Yetus - - - - - - - - - - - - - - - -

- - -

test-patch

- -

Purpose
Pre-requisites
Basic Usage
Automation
Build Tool
Providing Patch Files
Project-Specific Capabilities
MultiJDK
Docker
In Closing

- -

Purpose

- -

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.

- -

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.

- -

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.

- -

Pre-requisites

- -

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.

- -

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.

- -

Base Requirements

- -

test-patch requires these installed components to execute:

- -

git-based project (and git 1.7.3 or higher installed)
bash v3.2 or higher
GNU diff
GNU patch
POSIX awk
POSIX grep
POSIX sed
curl command
file command

- -

Optional Requirements

- -

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.

- -

Bug Systems:

- -

GitHub-based issue tracking
JIRA-based issue tracking
Bugzilla-based issue tracking (Read Only)

- -

Build Tools:

- -

ant
autoconf
cmake
gradle
make
maven

- -

Automation and Isolation:

- -

Docker version 1.6.0+
Jenkins

- -

Unit Test Formats:

- -

ctest
JUnit
TAP

- -

Language Support, Licensing, and more:

- -

Apache Creadur Rat entries in build system
checkstyle entries in build system (ant and maven only)
FindBugs entries in build system and 3.x executables
Perl::Critic installed
pylint installed
rubocop installed
ruby-lint installed
shellcheck installed, preferably 0.3.6 or higher

- -

Basic Usage

- -

The first step for a successful deployment is determining which features/plug-ins to enable:

$ test-patch.sh --list-plugins
-

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:

$ test-patch.sh --plugins="ant,maven,shellcheck,xml" <other options>
-

As a short-cut, every plug-in may be enabled via the special ‘all’ type:

$ test-patch.sh --plugins="all" <other options>
-

--plugins also allows some basic arithmetic:

$ test-patch.sh --plugins="all,-checkstyle,-findbugs" <other options>
-

This will enable all plug-ins for potential usage, except for checkstyle and findbugs.

- -

NOTE: The examples in this section will assume that the necessary --plugins option has been set on the command line as appropriate for your particular installation.

- -

This command will execute basic patch testing against a patch file stored in filename:

$ cd <your repo>
-$ test-patch.sh --dirty-workspace --project=projectname <filename>
-

The --dirty-workspace 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.

- -

To do turn them on, we need to provide the –run-tests option:

$ cd <your repo>
-$ test-patch.sh --dirty-workspace --run-tests <filename>
-

This is the same command, but now runs the unit tests.

- -

A typical configuration is to have two repositories. One with the code you are working on and another, clean repository. This means you can:

$ cd <workrepo>
-$ git diff master > /tmp/patchfile
-$ cd ../<testrepo>
-$ test-patch.sh --basedir=<testrepo> --resetrepo /tmp/patchfile
-

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 destructive mode. Destructive mode will wipe out any changes made to that repository, so use it with care!

- -

Automation

- -

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 --patch-dir 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.

- -

For example:

$ test-patch.sh --robot --patch-dir=${WORKSPACE}/patchprocess --basedir=${WORKSPACE}/source ${WORKSPACE}/patchfile
-

… 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 containers after 24 hours and images after 1 week, forcibly use –resetrepo, and more.

- -

NOTE: Make sure to add the patch directory to .gitignore if the directory is inside the source tree to avoid deleting it, as test-patch does a git clean to remove untracked files from previous runs.

- -

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:

$ test-patch.sh --robot --build-url=http://server.example.name:80/${buildnumber}/
-

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:

$ test-patch.sh --robot --instance=1
-

If –robot is specified without an instance, a random number is generated and used.

- -

There is some special handling if Jenkins is actually your automation tool. Instead of using –robot, use –jenkins:

$ test-patch.sh --jenkins --patch-dir=${WORKSPACE}/patchprocess --basedir=${WORKSPACE}/source ${WORKSPACE}/patchfile
-

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}.

- -

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.

- -

Build Tool

- -

Out of the box, test-patch is built to use maven. But what if the project is built using something else, such as ant?

$ test-patch.sh (other options) --build-tool=ant
-

will tell test-patch to use ant instead of maven to drive the project.

- -

Providing Patch Files

- -

JIRA

- -

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 last attachment, download it, then process it.

- -

NOTE: test-patch expects the patch files to follow a particular naming convention. For complete details - on the naming convention please refer to patch-naming-conventions

- -

For example:

$ test-patch.sh (other options) HADOOP-9905
-

… will process the patch file associated with this JIRA issue.

- -

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.

$ test-patch.sh --jira-issue-re='^PROJECT-[0-9]+$' --jira-base-url='https://example.com/jira' PROJECT-90
-

… will process the patch file attached to PROJECT-90 on the JIRA instance located on the example.com server.

- -

GITHUB

- -

test-patch has some basic support for Github. test-patch supports many forms of providing pull requests to work on:

$ test-patch.sh --github-repo=apache/pig GH:99
-

$ test-patch.sh https://github.com/apache/pig/pulls/99
-

$ test-patch.sh https://github.com/apache/pig/pulls/99.patch
-

… will process PR #99 on the apache/pig repo.

- -

Generic URLs

- -

Luckily, test-patch supports ways to provide unified diffs via URLs.

- -

For example:

$ test-patch.sh (other options) https://example.com/webserver/file.patch
-

… will download and process the file.patch from the example.com webserver.

- -

Project-specific Capabilities

- -

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:

- -

Direct Method

$ test-patch.sh (other options) --personality=(filename)
-

This tells test-patch to use the personality in the given file.

- -

Project Method

- -

However, test-patch can detect if it is a personality that is in its personality directory based upon the project name:

$ test-patch.sh (other options) --project=(project)
-

MultiJDK

- -

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:

$ test-patch.sh (other options) --multijdkdirs="/j/d/k/1,/j/d/k/2"
-

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.

- -

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.

- -

Docker

- -

test-patch also has a mode to utilize Docker:

$ test-patch.sh (other options) --docker
-

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.

- -

In Closing

- -

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.

- -

- - - http://git-wip-us.apache.org/repos/asf/yetus/blob/4a356e40/documentation/0.5.0/precommit-bugsystems/index.html ---------------------------------------------------------------------- diff --git a/documentation/0.5.0/precommit-bugsystems/index.html b/documentation/0.5.0/precommit-bugsystems/index.html deleted file mode 100644 index e2e3967..0000000 --- a/documentation/0.5.0/precommit-bugsystems/index.html +++ /dev/null @@ -1,213 +0,0 @@ - - - - - - Apache Yetus - - - - - - - - - - - - - - - -

- - -

Bug System Support

- -

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:

add_bugsystem <pluginname>
-

pluginname_locate_patch
- -
- Given input from the user, download the patch if possible.
pluginname_determine_branch
- -
- Using any heuristics available, return the branch to process, if possible.
pluginname_determine_issue
- -
- Using any heuristics available, set the issue, bug number, etc, for this bug system, if possible. This is typically used to fill in supplementary information in the final output table.
pluginname_write_comment
- -
- Given text input, write this output to the bug system as a comment. NOTE: It is the bug system’s responsibility to format appropriately.
pluginname_linecomments
- -
- This function allows for the system to write specific comments on specific lines if the bug system supports code review comments.
pluginname_finalreport
- -
- Write the final result table to the bug system.

- -

Bugzilla Specific

- -

Currently, Bugzilla support is read-only. To use it, the Bug ID must be preferenced with ‘BZ:’. For example:

$ test-patch.sh (other options) BZ:4
-

… will pull down Bugzilla ID #4.

- -

Using the --bugzilla-base-url 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 https://bz.apache.org/bugzilla .

- -

GitHub Specific

- -

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.

- -

By default, the GitHub plug-in assumes that https://github.com is the base URL for GitHub. Enterprise users may override this with the --github-base-url for the normal web user interface and --github-api-url for the API URL. Personalities may use GITHUB_API_URL and GITHUB_BASE_URL.

- -

The specific repository on GitHub is defined with either --github-repo on the command line or GITHUB_REPO in a personality. It should take the form of user/repo.

- -

In order to comment on issues or, depending upon the security setup of the repo, authentication credentials. The GitHub plug-in supports two types:

- -

Token-based: --github-token or GITHUB_TOKEN
Username/password: --github-user/ GITHUB_USER , --github-password / GITHUB_PASSWD

- -

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.

- -

JIRA Specific

- -

JIRA support allows both patch downloads and summary writes. It also supports branch detection-based upon the name of the attached patch file.

- -

JIRA issues are invoked by matching the command line option to a specific regular expression as given by the --jira-issue-re option or via the JIRA_ISSUE_RE personality variable. By default, the plug-in uses https://issues.apache.org/jira as the JIRA instance to use. However that may be overwritten via the --jira-base-url option or personalities may define via JIRA_URL.

- -

In order to write information on the issue, JIRA requires username and password authentication using the --jira-user/--jira-password options or the JIRA_USER and JIRA_PASSWORD variables in a personality.

- -

- - - http://git-wip-us.apache.org/repos/asf/yetus/blob/4a356e40/documentation/0.5.0/precommit-buildtools/index.html ---------------------------------------------------------------------- diff --git a/documentation/0.5.0/precommit-buildtools/index.html b/documentation/0.5.0/precommit-buildtools/index.html deleted file mode 100644 index 113bcf4..0000000 --- a/documentation/0.5.0/precommit-buildtools/index.html +++ /dev/null @@ -1,308 +0,0 @@ - - - - - - Apache Yetus - - - - - - - - - - - - - - - -

- - -

Build Tool Support

- -

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:

add_build_tool <pluginname>
-

Global Variables

- -

BUILDTOOLCWD
- -
- This variable determines where the build tool’s command (as returned by pluginname_executor) should actually execute. It should be one of three values:
- basedir - always execute at the root of the source tree
- module - switch to the directory as given by the module being processed
- /(path) - change to the directory as given by this absolute path. If the path does not exist, it will be created.

- -

If /(path) is used, two special substitutions may be made:

- -

@@@BASEDIR@@@ will be replaced with the root of the source tree
@@@MODULEDIR@@@ will be replaced with the module name

- -

This allows for custom directories to be created and used as necessary.

The default is module.
-

UNSUPPORTED_TEST
- -
- If pluginname_modules_worker is given a test type that is not supported by the build system, set UNSUPPORTED_TEST=true. If it is supported, set UNSUPPORTED_TEST=false.

- -

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.

- -

Required Functions

- -

pluginname_buildfile
- -
- This should be an echo of the file that controls the build system. This is used for module determination. If the build system wishes to disable module determination, it should echo with no args.
pluginname_executor
- -
- This should be an echo of how to run the build tool, any extra arguments, etc.
pluginname_modules_worker
- -
- Input is the branch and the test being run. This should call modules_workers 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 module_workers should be called with ‘test’ appended onto its normal parameters.
pluginname_builtin_personality_modules
- -
- Default method to determine how to enqueue modules for processing. Note that personalities may override this function. Requires two arguments: repo status and test desired. For example, in a maven build, values may be ‘branch’ and ‘mvninstall’.
pluginname_builtin_personality_file_tests
- -
- Default method to determine which tests to trigger. Note that personalities may override this function. Requires a single argument: the file in which the tests exist.

- -

Optional Functions

- -

pluginname_parse_args
- -
- executed prior to any other above functions except for pluginname_usage. This is useful for parsing the arguments passed from the user and setting up the execution environment.
pluginname_initialize
- -
- After argument parsing and prior to any other work, the initialize step allows a plug-in to do any precursor work, set internal defaults, etc.
pluginname_reorder_modules
- -
- This functions allows the plugin to (re-)order the modules (e.g. based on the output of the maven dependency plugin). When called CHANGED_MODULES[@] already contains all changed modules. It must be altered to have an effect.
pluginname_(test)_logfilter
- -
- This functions should filter all lines relevant to this test from the logfile. It is called in preparation for the calcdiffs function. The test plug-in name should be in the (test) part of the function name.
pluginname_(test)_calcdiffs
- -
- Some build tools (e.g., maven) use custom output for certain types of compilations (e.g., java). This allows for custom log file difference calculation used to determine the before and after views.
pluginname_docker_support
- -
- If this build tool requires extra settings on the docker run command line, this function should be defined and add those options into an array called ${DOCKER_EXTRAARGS[@]}. This is particularly useful for things like mounting volumes for repository caches.
- -
WARNING: Be aware that directories that do not exist MAY be created by root by Docker itself under certain conditions. It is HIGHLY recommend that pluginname_initialize be used to create the necessary directories prior to be used in the docker run command.

- -

Ant Specific

- -

Command Arguments

- -

test-patch always passes -noinput to Ant. This forces ant to be non-interactive.

- -

Docker Mode

- -

In Docker mode, the ${HOME}/.ivy2 directory is shared amongst all invocations.

- -

autoconf Specific

- -

autoconf requires make to be enabled. autoreconf is always used to rebuild the configure scripte.

- -

Command Arguments

- -

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.

- -

CMAKE Specific

- -

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.

- -

Gradle Specific

- -

The gradle plug-in always rebuilds the gradlew file and uses gradlew as the method to execute commands.

- -

In Docker mode, the ${HOME}/.gradle directory is shared amongst all invocations.

- -

Make Specific

- -

No notes.

- -

Maven Specific

- -

Command Arguments

- -

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.

- -

Per-instance Repositories

- -

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 mvn install command to be used.

- -

To assist, test-patch supports a --mvn-custom-repo option to set the -Dmaven.repo.local value to a per-instance repository directory keyed to the project and branch being used for the test. If the --jenkins flag is also passed, the instance will be tied to the Jenkins ${EXECUTOR_NUMBER} value. Otherwise, the instance value will be randomly generated via ${RANDOM}. If the repository has not been used in 30 days, it will be automatically deleted when any test run for that project (regardless of branch!).

- -

By default, test-patch uses ${HOME}/yetus-m2 as the base directory to store these custom maven repositories. That location may be changed via the --mvn-custom-repos-dir option.

- -

The location of the settings.xml may be changed via the --mvn-settings option.

- -

Docker Mode

- -

In Docker mode, ${HOME}/.m2 is shared amongst all invocations. If --mvn-custom-repos is used, all of --mvn-custom-repos-dir is shared with all invocations. The per-instance directory will be calculated and configured after Docker has launched.

- -

Test Profile

- -

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.

- -

Custom Maven Tests

- -

Maven will test eclipse and site if maven is being used as the build tool and appropriate files trigger them.

- -

Maven will trigger add a maven install test when the maven_add_install 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 Apache Yetus provided plug-ins that require maven will trigger the maven install functionality.

- -

- - - http://git-wip-us.apache.org/repos/asf/yetus/blob/4a356e40/documentation/0.5.0/precommit-docker-cleanup/index.html ---------------------------------------------------------------------- diff --git a/documentation/0.5.0/precommit-docker-cleanup/index.html b/documentation/0.5.0/precommit-docker-cleanup/index.html deleted file mode 100644 index 8cfe9c7..0000000 --- a/documentation/0.5.0/precommit-docker-cleanup/index.html +++ /dev/null @@ -1,175 +0,0 @@ - - - - - - Apache Yetus - - - - - - - - - - - - - - - -

- - -

docker-cleanup

- -

docker-cleanup is a command to perform precommit’s Docker cleanup functionality outside of patch and build testing.

- -

Usage

- -

Executing docker-cleanup will peform the same Docker image as the --robot option.

$ docker-cleanup
-
-...
-        Removing old images
-...
-Untagged: hadoop/createrelease:3.0.0-alpha3-SNAPSHOT_10600
-Deleted: sha256:1a96c79a0a9ab538c6c7765dc908eca3e689270b778d6ae2add558e89792a7d8
-...
-                       Docker Container Maintenance
-...
-
-

docker-cleanup also supports the --sentinel mode to kill and remove stale running containers:

$ docker-cleanup --sentinel
-
-...
-                            Removing old images
-...
-Untagged: hadoop/createrelease:3.0.0-alpha3-SNAPSHOT_10600
-Deleted: sha256:1a96c79a0a9ab538c6c7765dc908eca3e689270b778d6ae2add558e89792a7d8
-...
-
-                       Docker Container Maintenance
-...
-Attempting to remove docker container /big_kowalevski [5ffd22a56ebcfe38d72b9078e0e7133ab6dc054115a4804e504c910bdbdeea45]
-...
-

- -

- - - http://git-wip-us.apache.org/repos/asf/yetus/blob/4a356e40/documentation/0.5.0/precommit-glossary/index.html ---------------------------------------------------------------------- diff --git a/documentation/0.5.0/precommit-glossary/index.html b/documentation/0.5.0/precommit-glossary/index.html deleted file mode 100644 index 2ca8a5f..0000000 --- a/documentation/0.5.0/precommit-glossary/index.html +++ /dev/null @@ -1,173 +0,0 @@ - - - - - - Apache Yetus - - - - - - - - - - - - - - - -

- - -

Glossary

- -

Generic/outside definitions:

- -

Apache’s new contributor documentation and Maven’s glossary are great places to start if you are new to Apache or Maven.

- -

Module

- -

Almost the same meaning as sub-project on Maven.

- -

test-patch specific

- -

Personality

- -

A chunk of shell code that tells test-patch this particular project’s needs and special requirements

- -

Plug-ins

- -

Shell code snippets that define new, not built-in test types.

- -

Precommit

- -

An automated process that verifies a patch is good prior to a committer looking at it.

- -

- - - http://git-wip-us.apache.org/repos/asf/yetus/blob/4a356e40/documentation/0.5.0/precommit-patchnames/index.html ---------------------------------------------------------------------- diff --git a/documentation/0.5.0/precommit-patchnames/index.html b/documentation/0.5.0/precommit-patchnames/index.html deleted file mode 100644 index 92a1138..0000000 --- a/documentation/0.5.0/precommit-patchnames/index.html +++ /dev/null @@ -1,172 +0,0 @@ - - - - - - Apache Yetus - - - - - - - - - - - - - - - -

- - -

We use Apache Yetus to process your patch. It supports the following patterns and -procedures for patch file names:

- -

JIRA

- -

If JIRA support is configured, attach the patch to the given ISSUE and -click ‘Submit Patch’. The patch file should be named one of:

- -

ISSUE.patch
ISSUE.###.patch
ISSUE.branch.###.patch
ISSUE-branch-###.patch
ISSUE.###.branch.patch
ISSUE-branch.###.patch

- -

The meaning of the subpart are the following:

- -

ISSUE: JIRA key (e.g. YETUS-1)
branch: either the name of a branch or a git hash prefixed with git (e.g. branch-2.8 or git8e55427b35)
###: revision of the patch (e.g. 00 or 01)

- -

Github

- -

If Github support is also configured, a comment that contains a link to a Pull Request’s -patch file (e.g., https://github.com/user/repo/pull/1.patch) will pull the patch from -the given Github PR.

- -

- - -