X-Mailer: ASF-Git Admin Mailer Subject: [03/49] yetus git commit: git hash a444ed18a504a2378f0cd1c6223105f0d1a78416 archived-at: Thu, 13 Jul 2017 21:13:19 -0000 http://git-wip-us.apache.org/repos/asf/yetus/blob/6ca1d766/documentation/0.5.0/precommit-qbt/index.html ---------------------------------------------------------------------- diff --git a/documentation/0.5.0/precommit-qbt/index.html b/documentation/0.5.0/precommit-qbt/index.html new file mode 100644 index 0000000..ddcba4d --- /dev/null +++ b/documentation/0.5.0/precommit-qbt/index.html @@ -0,0 +1,198 @@ + + + + + + Apache Yetus + + + + + + + + + + + + + + + +

+ + +

qbt

+ +

qbt is a command to execute test-patch without a patch. It uses +the same plug-ins and the same options as test-patch. The only +difference is that no patch file, location, etc should be supplied. +It is meant to be a way to easily get test-patch’s output on your +current source tree. It is suitable to be run as a regularly +scheduled build as part of your overall development strategy.

+ +

Reporting

+ +

When using an automation tool, it may be useful to use the +--console-report-file option to send the summary email to a +file. This can then be used with systems like Jenkin’s +email-ext plug-in to send the output as an emailed report:

${FILE,path="<report-file-path>"}
+

For something a bit more structured, there is also the --html-report-file +option. Using this output, again with Jenkins’ email-ext plug-in, it is +possible to build some very nice looking output that is easily customized:

<html>
+<head>
+<style>
+table {
+    border-collapse: collapse;
+}
+table, th, td {
+   border: 1px solid black;
+}
+tr:nth-child(even){background-color: #f2f2f2}
+</style>
+</head>
+<body>
+<p>See the <a href="${BUILD_URL}">Jenkins Build</a> for more information.</p>
+<p>${CHANGES, format="<div>[%d] (%a) %m</div>"}</p>
+<p></p>
+${FILE,path="<report-file-path>"}
+</body></html>
+

If your mailing lists do not allow HTML-formatted email, then the --brief-report-file +provides a solution. This option creates a very plain, reduced content text file +suitable for email. It contains just the barebones information needed to get +information on failures: what voted -1, what tests failed, what subsystems are long +running (configurable with the --brief-report-long opton), and a list of any +attached log files.

+ +

NOTE: Be aware that ASF mailing lists do not allow HTML formatted email.

+ +

Archiving

+ +

It may be useful to save off certain files while qbt is running for more +post-processing by another utility. If the rsync command is available, +then the archiving functionality may be used.

+ +

The --archive-list option takes a comma separated list of find -name +patterns and copies them to the patch directory’s archiver subdirectory. +It will preserve the directory structure of the source tree so that +multiple matching file names will be preserved.

+ +

+ + + http://git-wip-us.apache.org/repos/asf/yetus/blob/6ca1d766/documentation/0.5.0/precommit-smart-apply-patch/index.html ---------------------------------------------------------------------- diff --git a/documentation/0.5.0/precommit-smart-apply-patch/index.html b/documentation/0.5.0/precommit-smart-apply-patch/index.html new file mode 100644 index 0000000..2446afa --- /dev/null +++ b/documentation/0.5.0/precommit-smart-apply-patch/index.html @@ -0,0 +1,164 @@ + + + + + + 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 simplest 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.5.0/precommit-testformats/index.html ---------------------------------------------------------------------- diff --git a/documentation/0.5.0/precommit-testformats/index.html b/documentation/0.5.0/precommit-testformats/index.html new file mode 100644 index 0000000..c60fd60 --- /dev/null +++ b/documentation/0.5.0/precommit-testformats/index.html @@ -0,0 +1,161 @@ + + + + + + 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>
+

Test format plugins can provide following two methods, which will be called by test-patch if defined.

+ +

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.

+ +

For an example of how to write a test-format plugin, you can look at junit plugin bundled in Apache Yetus.

+ +

+ + + http://git-wip-us.apache.org/repos/asf/yetus/blob/6ca1d766/documentation/0.5.0/releasedocmaker/index.html ---------------------------------------------------------------------- diff --git a/documentation/0.5.0/releasedocmaker/index.html b/documentation/0.5.0/releasedocmaker/index.html new file mode 100644 index 0000000..4cdb166 --- /dev/null +++ b/documentation/0.5.0/releasedocmaker/index.html @@ -0,0 +1,293 @@ + + + + + + Apache Yetus + + + + + + + + + + + + + + + +

+ + +

releasedocmaker

+ +

Purpose
Requirements
Basic Usage
Changing the Header
Multiple Versions
Unreleased Dates
Sorted Output
Backward Incompatible Changes
Lint Mode
Index Mode
Release Version

+ +

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.

+ +

Requirements

+ +

Python 2.6 with dateutil extension

+ +

dateutil may be installed via pip: pip install python-dateutil

+ +

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!

+ +

Sorted Output

+ +

Different projects may find one type of sort better than another, depending upon their needs. releasedocmaker supports two types of sorts and each provides two different options in the direction for that sort.

+ +

Resolution Date-base Sort

+ +

By default, releasedocmaker will sort the output based upon the resolution date of the issue starting with older resolutions. This is the same as giving these options:

$ releasedocmaker.py --project falcon --version 0.6 --sorttype resolutiondate --sortorder older
+

The order can be reversed so that newer issues appear on top by providing the ‘newer’ flag:

$ releasedocmaker.py --project falcon --version 0.6 --sorttype resolutiondate --sortorder newer
+

In the case of multiple projects given on the command line, the projects will be interspersed.

+ +

Issue Number-based Sort

+ +

An alternative to the date-based sort is to sort based upon the issue id. This may be accomplished via:

$ releasedocmaker.py --project falcon --version 0.6 --sorttype issueid --sortorder asc
+

This will now sort by the issue id, listing them in lowest to highest (or ascending) order.

+ +

The order may be reversed to list them in highest to lowest (or descending) order by providing the appropriate flag:

$ releasedocmaker.py --project falcon --version 0.6 --sorttype issueid --sortorder desc
+

In the case of multiple projects given on the command line, the projects will be grouped and then sorted by issue id.

+ +

Backward Incompatible Changes

+ +

To check if an issue is backward-incompatible the releasedocmaker script first checks the Hadoop Flags field in the +issue. If this field is found to be blank then it searches for the ‘backward-incompatible’ label. You can override the +default value for this label by using –incompatiblelabel option e.g.

$ releasedocmaker.py --project falcon --version 0.6 --incompatiblelabel not-compatible
+

or equivalently using the shorter -X option

$ releasedocmaker.py --project falcon --version 0.6 -X not-compatible
+

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*-style version numbering system. +For example directories with names like 0.6, 1.2.2, 1.2alpha etc. will all be linked.

+ +

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

+ +

Release Version

+ +

You can find the version of the releasedocmaker that you are using by giving the -V option. This may be helpful in finding documentation for the version you are using.

$ releasedocmaker.py -V
+

+ +

+ + + http://git-wip-us.apache.org/repos/asf/yetus/blob/6ca1d766/documentation/in-progress/audience-annotations-apidocs/allclasses-frame.html ---------------------------------------------------------------------- diff --git a/documentation/in-progress/audience-annotations-apidocs/allclasses-frame.html b/documentation/in-progress/audience-annotations-apidocs/allclasses-frame.html index 6b35b41..a5b7aa3 100644 --- a/documentation/in-progress/audience-annotations-apidocs/allclasses-frame.html +++ b/documentation/in-progress/audience-annotations-apidocs/allclasses-frame.html @@ -2,10 +2,10 @@ - + -All Classes (Apache Yetus - Audience Annotations Component 0.5.0-SNAPSHOT API) - +All Classes (Apache Yetus - Audience Annotations Component 0.5.0 API) + http://git-wip-us.apache.org/repos/asf/yetus/blob/6ca1d766/documentation/in-progress/audience-annotations-apidocs/allclasses-noframe.html ---------------------------------------------------------------------- diff --git a/documentation/in-progress/audience-annotations-apidocs/allclasses-noframe.html b/documentation/in-progress/audience-annotations-apidocs/allclasses-noframe.html index 1a00430..3de6ed1 100644 --- a/documentation/in-progress/audience-annotations-apidocs/allclasses-noframe.html +++ b/documentation/in-progress/audience-annotations-apidocs/allclasses-noframe.html @@ -2,10 +2,10 @@ - + -All Classes (Apache Yetus - Audience Annotations Component 0.5.0-SNAPSHOT API) - +All Classes (Apache Yetus - Audience Annotations Component 0.5.0 API) + http://git-wip-us.apache.org/repos/asf/yetus/blob/6ca1d766/documentation/in-progress/audience-annotations-apidocs/constant-values.html ---------------------------------------------------------------------- diff --git a/documentation/in-progress/audience-annotations-apidocs/constant-values.html b/documentation/in-progress/audience-annotations-apidocs/constant-values.html index 6b1c09a..e1b873c 100644 --- a/documentation/in-progress/audience-annotations-apidocs/constant-values.html +++ b/documentation/in-progress/audience-annotations-apidocs/constant-values.html @@ -2,10 +2,10 @@ - + -Constant Field Values (Apache Yetus - Audience Annotations Component 0.5.0-SNAPSHOT API) - +Constant Field Values (Apache Yetus - Audience Annotations Component 0.5.0 API) + @@ -13,7 +13,7 @@ @@ -13,7 +13,7 @@ @@ -13,7 +13,7 @@ @@ -13,7 +13,7 @@ @@ -13,7 +13,7 @@ @@ -13,7 +13,7 @@ @@ -13,7 +13,7 @@ @@ -13,7 +13,7 @@ @@ -13,7 +13,7 @@ @@ -13,7 +13,7 @@ @@ -13,7 +13,7 @@ @@ -13,7 +13,7 @@ @@ -13,7 +13,7 @@ @@ -13,7 +13,7 @@ @@ -13,7 +13,7 @@ @@ -13,7 +13,7 @@ @@ -13,7 +13,7 @@ @@ -13,7 +13,7 @@ @@ -13,7 +13,7 @@ @@ -13,7 +13,7 @@