Return-Path: Now that the patch has been applied the steps to compile we outlined in the compilation (branch) phase are repeated but with the patch applied. This is where a lot of 'after’ checks are performed. Now that the patch has been applied the steps to compile we outlined in the compilation (branch) phase are repeated but with the patch applied. This is where a lot of ‘after’ checks are performed.
-
maven_add_install test
@@ -322,7 +321,6 @@
-
maven_delete_install test
@@ -360,7 +358,6 @@
-
bugzilla_write_comment filename
@@ -396,7 +393,6 @@
-
github_write_comment filename
@@ -432,7 +428,6 @@
-
javac_precheck
@@ -470,7 +465,6 @@
-
jira_write_comment filename
@@ -508,7 +502,6 @@
-
ant_buildfile
@@ -544,7 +537,6 @@
-
ant_builtin_personality_file_tests
@@ -580,7 +572,6 @@
-
ant_builtin_personality_modules
@@ -616,7 +607,6 @@
-
ant_docker_support
@@ -652,7 +642,6 @@
-
ant_executor
@@ -688,7 +677,6 @@
-
ant_filefilter
@@ -724,7 +712,6 @@
-
ant_initialize
@@ -760,7 +747,6 @@
-
ant_modules_worker
@@ -796,7 +782,6 @@
-
ant_parse_args
@@ -832,7 +817,6 @@
-
ant_usage
@@ -868,7 +852,6 @@
-
asflicense_parse_args
@@ -904,7 +887,6 @@
-
asflicense_usage
@@ -940,7 +922,6 @@
-
asflicense_writexsl
@@ -976,7 +957,6 @@
-
bugzilla_determine_issue
@@ -1012,7 +992,6 @@
-
bugzilla_http_fetch
@@ -1048,7 +1027,6 @@
-
bugzilla_locate_patch
@@ -1084,7 +1062,6 @@
-
bugzilla_parse_args
@@ -1120,7 +1097,6 @@
-
bugzilla_usage
@@ -1156,7 +1132,6 @@
-
cc_filefilter
@@ -1192,7 +1167,6 @@
-
checkstyle_filefilter
@@ -1228,7 +1202,6 @@
-
checkstyle_postapply
@@ -1264,7 +1237,6 @@
-
checkstyle_postcompile
@@ -1300,7 +1272,6 @@
-
checkstyle_preapply
@@ -1336,7 +1307,6 @@
-
findbugs_filefilter
@@ -1372,7 +1342,6 @@
-
findbugs_parse_args
@@ -1408,7 +1377,6 @@
-
findbugs_precheck
@@ -1444,7 +1412,6 @@
-
findbugs_rebuild
@@ -1480,7 +1447,6 @@
-
findbugs_usage
@@ -1516,7 +1482,6 @@
-
github_breakup_url url
@@ -1552,7 +1517,6 @@
-
github_determine_issue
@@ -1588,7 +1552,6 @@
-
github_find_jira_title
@@ -1624,7 +1587,6 @@
-
github_jira_bridge
@@ -1660,7 +1622,6 @@
-
github_linecomments
@@ -1696,7 +1657,6 @@
-
github_locate_patch
@@ -1732,7 +1692,6 @@
-
github_parse_args
@@ -1768,7 +1727,6 @@
-
github_usage
@@ -1804,7 +1762,6 @@
-
gradle_buildfile
@@ -1840,7 +1797,6 @@
-
gradle_builtin_personality_file_tests
@@ -1876,7 +1832,6 @@
-
gradle_builtin_personality_modules
@@ -1912,7 +1867,6 @@
-
gradle_docker_support
@@ -1948,7 +1902,6 @@
-
gradle_executor
@@ -1984,7 +1937,6 @@
-
gradle_filefilter
@@ -2020,7 +1972,6 @@
-
gradle_initialize
@@ -2056,7 +2007,6 @@
-
gradle_modules_worker
@@ -2092,7 +2042,6 @@
-
gradle_parse_args
@@ -2128,7 +2077,6 @@
-
gradle_usage
@@ -2164,7 +2112,6 @@
-
initialize_java
@@ -2200,7 +2147,6 @@
-
javac_filefilter
@@ -2236,7 +2182,6 @@
-
javac_initialize
@@ -2272,7 +2217,6 @@
-
javadoc_filefilter
@@ -2308,7 +2252,6 @@
-
javadoc_initialize
@@ -2344,7 +2287,6 @@
-
jira_determine_issue
@@ -2380,7 +2322,6 @@
-
jira_http_fetch
@@ -2416,7 +2357,6 @@
-
jira_locate_patch
@@ -2452,7 +2392,6 @@
-
jira_parse_args
@@ -2488,7 +2427,6 @@
-
jira_usage
@@ -2524,7 +2462,6 @@
-
junit_finalize_results
@@ -2560,7 +2497,6 @@
-
junit_process_tests
@@ -2596,7 +2532,6 @@
-
maven_buildfile
@@ -2632,7 +2567,6 @@
-
maven_builtin_personality_file_tests
@@ -2668,7 +2602,6 @@
-
maven_builtin_personality_modules
@@ -2704,7 +2637,6 @@
-
maven_docker_support
@@ -2740,7 +2672,6 @@
-
maven_executor
@@ -2776,7 +2707,6 @@
-
maven_filefilter
@@ -2812,7 +2742,6 @@
-
maven_initialize
@@ -2848,7 +2777,6 @@
-
maven_javac_logfilter
@@ -2884,7 +2812,6 @@
-
maven_modules_worker
@@ -2920,7 +2847,6 @@
-
maven_parse_args
@@ -2956,7 +2882,6 @@
-
maven_precheck
@@ -2992,7 +2917,6 @@
-
maven_usage
@@ -3028,7 +2952,6 @@
-
mvnsite_filefilter
@@ -3064,7 +2987,6 @@
-
nobuild_buildfile
@@ -3100,7 +3022,6 @@
-
nobuild_builtin_personality_file_tests
@@ -3136,7 +3057,6 @@
-
nobuild_builtin_personality_modules
@@ -3172,7 +3092,6 @@
-
nobuild_executor
@@ -3208,7 +3127,6 @@
-
nobuild_modules_worker
@@ -3244,7 +3162,6 @@
-
perlcritic_filefilter
@@ -3280,7 +3197,6 @@
-
perlcritic_parse_args
@@ -3316,7 +3232,6 @@
-
perlcritic_postapply
@@ -3352,7 +3267,6 @@
-
perlcritic_postcompile
@@ -3388,7 +3302,6 @@
-
perlcritic_preapply
@@ -3424,7 +3337,6 @@
-
perlcritic_precheck
@@ -3460,7 +3372,6 @@
-
perlcritic_usage
@@ -3496,7 +3407,6 @@
-
pylint_filefilter
@@ -3532,7 +3442,6 @@
-
pylint_parse_args
@@ -3568,7 +3477,6 @@
-
pylint_postapply
@@ -3604,7 +3512,6 @@
-
pylint_postcompile
@@ -3640,7 +3547,6 @@
-
pylint_preapply
@@ -3676,7 +3582,6 @@
-
pylint_precheck
@@ -3712,7 +3617,6 @@
-
pylint_usage
@@ -3748,7 +3652,6 @@
-
rubocop_filefilter
@@ -3784,7 +3687,6 @@
-
rubocop_parse_args
@@ -3820,7 +3722,6 @@
-
rubocop_postapply
@@ -3856,7 +3757,6 @@
-
rubocop_postcompile
@@ -3892,7 +3792,6 @@
-
rubocop_preapply
@@ -3928,7 +3827,6 @@
-
rubocop_precheck
@@ -3964,7 +3862,6 @@
-
rubocop_usage
@@ -4000,7 +3897,6 @@
-
ruby_lint_filefilter
@@ -4036,7 +3932,6 @@
-
ruby_lint_parse_args
@@ -4072,7 +3967,6 @@
-
ruby_lint_postapply
@@ -4108,7 +4002,6 @@
-
ruby_lint_postcompile
@@ -4144,7 +4037,6 @@
-
ruby_lint_preapply
@@ -4180,7 +4072,6 @@
-
ruby_lint_precheck
@@ -4216,7 +4107,6 @@
-
ruby_lint_usage
@@ -4252,7 +4142,6 @@
-
scalac_filefilter
@@ -4288,7 +4177,6 @@
-
scaladoc_filefilter
@@ -4324,7 +4212,6 @@
-
shellcheck_filefilter
@@ -4360,7 +4247,6 @@
-
shellcheck_postapply
@@ -4396,7 +4282,6 @@
-
shellcheck_postcompile
@@ -4432,7 +4317,6 @@
-
shellcheck_preapply
@@ -4468,7 +4352,6 @@
-
shellcheck_precheck
@@ -4504,7 +4387,6 @@
-
shellcheck_private_findbash
@@ -4540,7 +4422,6 @@
-
shelldocs_filefilter
@@ -4576,7 +4457,6 @@
-
shelldocs_parse_args
@@ -4612,7 +4492,6 @@
-
shelldocs_postapply
@@ -4648,7 +4527,6 @@
-
shelldocs_postcompile
@@ -4684,7 +4562,6 @@
-
shelldocs_preapply
@@ -4720,7 +4597,6 @@
-
shelldocs_precheck
@@ -4756,7 +4632,6 @@
-
shelldocs_private_findbash
@@ -4792,7 +4667,6 @@
-
shelldocs_usage
@@ -4828,7 +4702,6 @@
-
tap_finalize_results
@@ -4864,7 +4737,6 @@
-
tap_parse_args
@@ -4900,7 +4772,6 @@
-
tap_process_tests
@@ -4936,7 +4807,6 @@
-
tap_usage
@@ -4972,7 +4842,6 @@
-
unitveto_filefilter
@@ -5008,7 +4877,6 @@
-
unitveto_parse_args
@@ -5044,7 +4912,6 @@
-
unitveto_patchfile
@@ -5080,7 +4947,6 @@
-
unitveto_usage
@@ -5116,7 +4982,6 @@
-
whitespace_linecomment_reporter
@@ -5152,7 +5017,6 @@
-
whitespace_postcompile
@@ -5188,7 +5052,6 @@
-
xml_filefilter
@@ -5224,7 +5087,6 @@
-
xml_postcompile
@@ -5260,7 +5122,6 @@
-
xml_precheck
http://git-wip-us.apache.org/repos/asf/yetus/blob/012f133c/documentation/0.2.1/precommit-apidocs/smart-apply-patch/index.html
----------------------------------------------------------------------
diff --git a/documentation/0.2.1/precommit-apidocs/smart-apply-patch/index.html b/documentation/0.2.1/precommit-apidocs/smart-apply-patch/index.html
index 6ac9d5d..09b916b 100644
--- a/documentation/0.2.1/precommit-apidocs/smart-apply-patch/index.html
+++ b/documentation/0.2.1/precommit-apidocs/smart-apply-patch/index.html
@@ -149,7 +149,6 @@
-
setup_defaults
@@ -185,7 +184,6 @@
-
yetus_usage
@@ -223,7 +221,6 @@
-
add_footer_table
@@ -259,7 +256,6 @@
-
add_test
@@ -295,7 +291,6 @@
-
add_vote_table
@@ -331,7 +326,6 @@
-
big_console_header
http://git-wip-us.apache.org/repos/asf/yetus/blob/012f133c/documentation/0.2.1/precommit-apidocs/test-patch/index.html
----------------------------------------------------------------------
diff --git a/documentation/0.2.1/precommit-apidocs/test-patch/index.html b/documentation/0.2.1/precommit-apidocs/test-patch/index.html
index ec9b8ab..7ea2c66 100644
--- a/documentation/0.2.1/precommit-apidocs/test-patch/index.html
+++ b/documentation/0.2.1/precommit-apidocs/test-patch/index.html
@@ -199,7 +199,6 @@
-
relative_dir path
@@ -237,7 +236,6 @@
-
verify_multijdk_test test
@@ -277,7 +275,6 @@
-
add_footer_table subsystem string
@@ -313,7 +310,6 @@
-
add_header_line string
@@ -349,7 +345,6 @@
-
add_test_table failurereason testlist
@@ -385,7 +380,6 @@
-
add_vote_table +1/0/-1/null subsystem string
@@ -421,7 +415,6 @@
-
big_console_header string
@@ -457,7 +450,6 @@
-
clock_display seconds
@@ -493,7 +485,6 @@
-
echo_and_redirect filename command [..]
@@ -529,7 +520,6 @@
-
generate_stack
@@ -565,7 +555,6 @@
-
module_file_fragment module
@@ -601,7 +590,6 @@
-
offset_clock seconds
@@ -637,7 +625,6 @@
-
setup_defaults
@@ -673,7 +660,6 @@
-
start_clock
@@ -709,7 +695,6 @@
-
stop_clock
@@ -745,7 +730,6 @@
-
write_comment filename
@@ -781,7 +765,6 @@
-
yetus_usage
@@ -819,7 +802,6 @@
-
bugsystem_linecomments filename
@@ -855,7 +837,6 @@
-
buildtool_cwd MODULE_ index
@@ -891,7 +872,6 @@
-
calcdiffs branchlog patchlog testtype
@@ -927,7 +907,6 @@
-
clear_personality_queue
@@ -963,7 +942,6 @@
-
column_calcdiffs branchlog patchlog
@@ -999,7 +977,6 @@
-
compile branch|patch
@@ -1037,7 +1014,6 @@
-
compile_cycle branch|patch
@@ -1075,7 +1051,6 @@
-
compile_jvm branch|patch
@@ -1113,7 +1088,6 @@
-
compile_nonjvm branch|patch
@@ -1151,7 +1125,6 @@
-
dequeue_personality_module modulenames
@@ -1187,7 +1160,6 @@
-
distclean
@@ -1225,7 +1197,6 @@
-
error_calcdiffs branchlog patchlog
@@ -1261,7 +1232,6 @@
-
generic_calcdiff_status totalbranchissues totalpatchissues newpatchissues
@@ -1297,7 +1267,6 @@
-
generic_logfilter
@@ -1333,7 +1302,6 @@
-
generic_post_handler origlog testtype multijdkmode run commands
@@ -1371,7 +1339,6 @@
-
generic_postlog_compare origlog testtype multijdkmode
@@ -1409,7 +1376,6 @@
-
generic_pre_handler testype multijdk
@@ -1447,7 +1413,6 @@
-
initialize $@
@@ -1485,7 +1450,6 @@
-
module_status module runtime
@@ -1521,7 +1485,6 @@
-
modules_messages repostatus testtype summarymode
@@ -1557,7 +1520,6 @@
-
modules_reset
@@ -1593,7 +1555,6 @@
-
modules_workers repostatus testtype mvncmdline
@@ -1629,7 +1590,6 @@
-
patchfiletests branch|patch
@@ -1667,7 +1627,6 @@
-
personality_enqueue_module module profiles/flags/etc
@@ -1705,7 +1664,6 @@
-
prepopulate_footer
@@ -1741,7 +1699,6 @@
-
report_jvm_version directory
@@ -1779,7 +1736,6 @@
-
verify_patchdir_still_exists
http://git-wip-us.apache.org/repos/asf/yetus/blob/012f133c/documentation/0.2.1/precommit-architecture/index.html
----------------------------------------------------------------------
diff --git a/documentation/0.2.1/precommit-architecture/index.html b/documentation/0.2.1/precommit-architecture/index.html
index e6ebcf6..c5db746 100644
--- a/documentation/0.2.1/precommit-architecture/index.html
+++ b/documentation/0.2.1/precommit-architecture/index.html
@@ -191,7 +191,7 @@
Compile Cycle (Patch)
-Unit Tests
http://git-wip-us.apache.org/repos/asf/yetus/blob/012f133c/documentation/0.2.1/precommit-basic/index.html
----------------------------------------------------------------------
diff --git a/documentation/0.2.1/precommit-basic/index.html b/documentation/0.2.1/precommit-basic/index.html
index e57c712..5c1a190 100644
--- a/documentation/0.2.1/precommit-basic/index.html
+++ b/documentation/0.2.1/precommit-basic/index.html
@@ -223,19 +223,15 @@ as a whole.
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.
$ 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:
@@ -260,7 +254,6 @@ as a whole. $ 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!
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 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:
$ 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.
@@ -295,7 +284,6 @@ have a location to look at the output artifacts: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.
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.
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 99
-
or
$ test-patch.sh https://github.com/apache/pig/pulls/99
-
or
$ test-patch.sh https://github.com/apache/pig/pulls/99.patch
-
… will process PR #99 on the apache/pig repo.
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.
$ test-patch.sh (other options) --personality=(filename)
-
This tells test-patch to use the personality in the given file.
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)
-
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.
@@ -373,7 +352,6 @@ have a location to look at the output artifacts: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.
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
@@ -166,7 +165,6 @@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 .
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>
-
This allows for custom directories to be created and used as necessary.
The default is module.
-
UNSUPPORTED_TEST
@@ -178,7 +176,7 @@pluginname_modules_worker
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.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
@@ -254,7 +252,7 @@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.
+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.
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:
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
http://git-wip-us.apache.org/repos/asf/yetus/blob/012f133c/documentation/0.2.1/releasedocmaker/index.html ---------------------------------------------------------------------- diff --git a/documentation/0.2.1/releasedocmaker/index.html b/documentation/0.2.1/releasedocmaker/index.html index e2017d0..5477ad9 100644 --- a/documentation/0.2.1/releasedocmaker/index.html +++ b/documentation/0.2.1/releasedocmaker/index.html @@ -153,7 +153,6 @@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.
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
-
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.
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.
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!
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.