X-Mailer: ASF-Git Admin Mailer Subject: [41/49] yetus git commit: git hash a444ed18a504a2378f0cd1c6223105f0d1a78416 archived-at: Thu, 13 Jul 2017 21:13:23 -0000 http://git-wip-us.apache.org/repos/asf/yetus/blob/6ca1d766/documentation/0.1.0/precommit-bugsystems/index.html ---------------------------------------------------------------------- diff --git a/documentation/0.1.0/precommit-bugsystems/index.html b/documentation/0.1.0/precommit-bugsystems/index.html deleted file mode 100644 index 821258f..0000000 --- a/documentation/0.1.0/precommit-bugsystems/index.html +++ /dev/null @@ -1,214 +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/6ca1d766/documentation/0.1.0/precommit-buildtools/index.html ---------------------------------------------------------------------- diff --git a/documentation/0.1.0/precommit-buildtools/index.html b/documentation/0.1.0/precommit-buildtools/index.html deleted file mode 100644 index 06970bd..0000000 --- a/documentation/0.1.0/precommit-buildtools/index.html +++ /dev/null @@ -1,274 +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
- -
- If the build tool does not always run from the ${BASEDIR} and instead needs to change the current working directory to work on a specific module, then set this to true. The default is false.
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.
pluginname_builtin_personality_file_tests
- -
- Default method to determine which tests to trigger. Note that personalities may override this function.

- -

Optional Functions

- -

pluginname_postapply_install
- -
- After the install step, this allows the build tool plug-in to do extra work.
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_count_(test)_probs
- -
- Certain language test plug-ins require assistance from the build tool to count problems in the compile log due to some tools having custom handling for those languages. The test plug-in name should be in the (test) part of the function name.
pluginname_docker_support
- -
- If this build tool requires extra settings on the docker run command line, this function should be defined and write those options into a file called ${PATCH_DIR}/buildtool-docker-params.txt. 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.

- -

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.

- -

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 trigger a maven install as part of the precompile.
Maven will test eclipse integration as part of the postcompile.
If src/site is modified, maven site tests are executed.

- -

- - - http://git-wip-us.apache.org/repos/asf/yetus/blob/6ca1d766/documentation/0.1.0/precommit-glossary/index.html ---------------------------------------------------------------------- diff --git a/documentation/0.1.0/precommit-glossary/index.html b/documentation/0.1.0/precommit-glossary/index.html deleted file mode 100644 index 6c03621..0000000 --- a/documentation/0.1.0/precommit-glossary/index.html +++ /dev/null @@ -1,174 +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/6ca1d766/documentation/0.1.0/precommit-patchnames/index.html ---------------------------------------------------------------------- diff --git a/documentation/0.1.0/precommit-patchnames/index.html b/documentation/0.1.0/precommit-patchnames/index.html deleted file mode 100644 index d53df5a..0000000 --- a/documentation/0.1.0/precommit-patchnames/index.html +++ /dev/null @@ -1,163 +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

- -

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.

- -

- - - http://git-wip-us.apache.org/repos/asf/yetus/blob/6ca1d766/documentation/0.1.0/precommit-smart-apply-patch/index.html ---------------------------------------------------------------------- diff --git a/documentation/0.1.0/precommit-smart-apply-patch/index.html b/documentation/0.1.0/precommit-smart-apply-patch/index.html deleted file mode 100644 index 35756be..0000000 --- a/documentation/0.1.0/precommit-smart-apply-patch/index.html +++ /dev/null @@ -1,167 +0,0 @@ - - - - - - Apache Yetus - - - - - - - - - - - - - - - -

- - -

smart-apply-patch

- -

smart-apply-patch 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.

- -

Usage

- -

Its simpliest form is used when a patch is stored in a local file:

$ smart-apply-patch patch
-

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.

- -

Perhaps you just want to see if the patch even applies without changing your local repo. The --dry-run option will just test for applicability:

$ smart-apply-patch --dry-run patch
-

For committers of projects, there is a special mode:

$ smart-apply-patch --committer patch
-

that in addition to applying the patch will also attempt to:

- -

use --whitespace=fix mode
add all newly created files in the repo
use --signoff and commit the change via git-am

- -

- - - http://git-wip-us.apache.org/repos/asf/yetus/blob/6ca1d766/documentation/0.1.0/precommit-testformats/index.html ---------------------------------------------------------------------- diff --git a/documentation/0.1.0/precommit-testformats/index.html b/documentation/0.1.0/precommit-testformats/index.html deleted file mode 100644 index 667b1c0..0000000 --- a/documentation/0.1.0/precommit-testformats/index.html +++ /dev/null @@ -1,160 +0,0 @@ - - - - - - Apache Yetus - - - - - - - - - - - - - - - -

- - -

Test Format Support

- -

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:

add_test_format <pluginname>
-

pluginname_process_tests
- -
- Given a path to the log file and tested module name, parse that file and store the test result into global variables and/or files.
pluginname_finalize_results
- -
- Using the results stored by pluginname_process_tests, write them to the test result table and/or the footer table for reporting.

- -

- - - http://git-wip-us.apache.org/repos/asf/yetus/blob/6ca1d766/documentation/0.1.0/releasedocmaker/index.html ---------------------------------------------------------------------- diff --git a/documentation/0.1.0/releasedocmaker/index.html b/documentation/0.1.0/releasedocmaker/index.html deleted file mode 100644 index 5477ad9..0000000 --- a/documentation/0.1.0/releasedocmaker/index.html +++ /dev/null @@ -1,242 +0,0 @@ - - - - - - Apache Yetus - - - - - - - - - - - - - - - -

- - -

releasedocmaker

- -

Purpose
Basic Usage
Changing the Header
Multiple Versions
Unreleased Dates
Lint Mode
Index Mode

- -

Purpose

- -

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:

- -

JIRA-generated release notes from the Release Notes button
Manually modified CHANGES file
Processing git log information

- -

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.

- -

In order to solve these problems, releasedocmaker was written to automatically generate a changelog and release notes by querying Apache’s JIRA instance.

- -

Basic Usage

- -

Minimally, the name of the JIRA project and a version registered in JIRA must be provided:

$ releasedocmaker.py --project (project) --version (version)
-

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.

- -

CHANGES.(version).md

- -

This is similar to the JIRA Release Notes button but is in tabular format and includes the priority, component, reporter, and contributor fields. It also highlights Incompatible Changes so that readers know what to look out for when upgrading. The top of the file also includes the date that the version was marked as released in JIRA.

- -

RELEASENOTES.(version).md

- -

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.

- -

For example, to build the release documentation for HBase v1.2.0…

$ releasedocmaker.py --project HBASE --version 1.2.0
-

… will create a 1.2.0 directory and inside that directory will be CHANGES.1.2.0.md and RELEASENOTES.1.2.0.md .

- -

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:

<!-- markdown -->
-remaining text
-

Changing the Header

- -

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:

$ releasedocmaker.py --project HBASE --version 1.2.0 --projecttitle "Apache HBase"
-

Now instead of HBASE, it will use Apache HBASE for some titles and headers.

- -

Multiple Versions

- -

The script can also generate multiple versions at once, by

$ releasedocmaker.py --project HBASE --version 1.0.0 --version 1.2.0
-

This will create the files for versions 1.0.0 and versions 1.2.0 in their own directories.

- -

But what if the version numbers are not known? releasedocmaker can also generate version data based upon ranges:

$ releasedocmaker.py --project HBASE --version 1.0.0 --version 1.2.0 --range
-

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.

- -

Unreleased Dates

- -

For released versions, releasedocmaker will pull the date of the release from JIRA. However, for unreleased versions it marks the release as Unreleased. This can be inconvenient when actually building a release and wanting to include it inside the source package.

- -

The –usetoday option can be used to signify that instead of using Unreleased, releasedocmaker should use today’s date.

$ releasedocmaker.py --project HBASE --version 1.0.0 --usetoday
-

After using this option and release, don’t forget to change JIRA’s release date to match!

- -

Lint Mode

- -

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.

- -

In order to help release managers from having to scan through potentially large documents, releasedocmaker features a lint mode, triggered via –lint:

$ releasedocmaker.py --project HBASE --version 1.0.0 --lint
-

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.

- -

Index Mode

- -

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.

- -

index.md: a file suitable for conversion to HTML via mvn site
README.md: a file suitable for display on Github and other Markdown rendering websites

- -

- - -