Dist::Zilla::Plugin::TravisYML - creates a .travis.yml file for Travis CI
[TravisYML] ; defaults build_branch = /^build\/.*/ notify_email = 1 notify_irc = 0 mvdt = 0 ; These options are probably a good idea ; if you are going to use a build_branch [Git::CommitBuild] release_branch = build/%b release_message = Release build of v%v (on %b) [@Git] allow_dirty = dist.ini allow_dirty = README allow_dirty = .travis.yml push_to = origin master:master push_to = origin build/master:build/master
This plugin creates a .travis.yml file in your distro for CI smoke testing (or what we like to call "chain smoking"). It will also (optionally) create a separate .travis.yml file for your build directory after a release.
.travis.yml
Why two files? Because chain smoking via DZIL will work a lot differently than a traditional Makefile.PL; make. This tests both your distribution repo environment as well as what a CPAN user would see.
Makefile.PL; make
Of course, you still need to turn on TravisCI and the remote still needs to be a GitHub repo for any of this to work.
This is a regular expression indicating which (build) branches are okay for running through Travis CI, per the configuration's branch whitelist option. The value will be inserted directly as an only clause. The default is /^build\/.*/.
only
/^build\/.*/
This more or less requires Git::CommitBuild to work. (Ordering is important, too. TravisYML comes before Git::CommitBuild.) You should change this to match up with the release_branch option, if your build branch is not going to reside in a build/* structure.
release_branch
build/*
Also, if you want to disable build branch testing, you can set this to 0.
0
This affects the notification options of the resulting YML file. It can either be set to:
0 = Disable email notification
1 = Enable email notification, using Travis CI's default email scheme
1
foo@bar.com (can be multiple; one per line) = Enable email notification to these email addresses
foo@bar.com
The default is 1.
0 = Disable IRC notification
1 = Enable IRC notification, using the IRC or x_irc meta resource value
IRC
x_irc
irc://irc.perl.org/#roomname (can be multiple; one per line) = Enable IRC notification to these IRC server/rooms
irc://irc.perl.org/#roomname
The default is 0. Please ask permission from the room channel operators before enabling bot notification.
Only applies when IRC notification is on. The default is:
%{branch}#%{build_number} by %{author}: %{message} (%{build_url})
This option can be specified more than once for multiple lines. See Travis-CI's IRC notification docs for a list of variables that can be used.
This is a space-delimited option with a list of the perl versions to test against. The default is all supported versions available within Travis, except for Perl 5.8. This is because there's still various DZIL plugins that require 5.10. (This may change in the future.)
You can restrict it down to only a few like this:
perl_version = 5.10 5.12
Note that any custom settings here will prevent any newer versions from being auto-added (as this distro is updated).
Turning this on enables Minimum Version Dependency Testing. This will make your YML file less of a static file, as it will now include commands to forcefully downgrade your dependencies to the lowest version that your prereqs said they would be able to use.
While going through the MVDT process is recommended, it can be a royal PITA sometimes, so this option isn't on by default. It's HIGHLY recommended that you read the above doc first to get an idea of what you're diving into.
This applies to both YML files.
Controls whether author dependencies will be tested while DZIL chainsmoking. This option is also directly linked to verbosity and parallelization of the author deps:
0 = No tests or verbosity, all files are downloaded/installed in parallel (10 processes at a time)
1 = Each module is downloaded one at a time, tested, and with verbosity turned on
The default is 0.
Just like test_authordeps, but for the real deps that the module needs. This also affects testing for build chainsmoking as well.
test_authordeps
For the most part, the default command sets for TravisYML serves its purpose. However, you may have some unusual situation from within your distro that demands a custom command or two. For that purpose, there is a set of "dynamic" options available to add or replace any part of the command list for Travis.
They are in the form of:
$pos$phase$filetype $pos = Either 'pre_' or 'post_' (optional) $phase = One of the Travis-CI testing phases (required) $filetype = Either '_dzil' or '_build' (optional)
See Travis-CI's Build Lifecycle for a list of phases.
The positions determine if the commands are to be added at the beginning (pre_), the end (post_), or replacing (no prefix) the existing code. Replace entire blocks at your own risk; TravisYML may change the original blocks for bug fixes or new features, and you wouldn't see them if they were replaced.
pre_
post_
The file type determines if these command changes are for the DZIL YML file (_dzil), the build YML file (_build), or both (no suffix).
_dzil
_build
For example, this would give you the following combinations for the 'before_install' phase:
before_install = Replace all before_install blocks pre_before_install = Unshift lines to all before_install blocks post_before_install = Push lines to all before_install blocks before_install_dzil = Replace DZIL before_install block pre_before_install_dzil = Unshift lines to DZIL before_install block post_before_install_dzil = Push lines to DZIL before_install block before_install_build = Replace build before_install block pre_before_install_build = Unshift lines to build before_install block post_before_install_build = Push lines to build before_install block
These options are all multi-lined, so you can add as many commands as you need:
pre_install_dzil = export AUTHOR_TESTING=1 pre_install_dzil = echo "Author testing is now "$AUTHOR_TESTING
A common question I get with this plugin is: "If .travis.yml is a static file, why bother with a plugin?"
Three reasons:
1. DZIL and Travis-CI interactions - If you look at the YML file itself, you'll notice that it's not a 5-line file. It's not as simple as telling Travis that this is a Perl distro and GO. Both Travis-CI and DZIL are ever changing platforms, and this plugin will keep things in sync with those two platforms. (For example, Travis VMs recently stopped using a valid name/email for git's user.* config items, which impacted DZIL smoking with certain Git plugins. So, TravisYML had to compensate.) I personally use this plugin myself, so if there are new issues that come up, I should be one of the first to notice.
2. Build branches - Build branches are great for having a perfect copy of your current release, giving non-DZIL folks a chance to submit patches, and for running a Travis-CI test on something that is close to the CPAN release as possible. However, setting that up can be tricky, and it requires a second YML file just for the build branch. TravisYML manages that by hiding the DZIL .travis.yml file prior to building, and then creating a new one after release (but before the build branch is commited).
3. MVDT - If you want to brave through the Minimum Version Dependency Testing process, this will automate the YML generation for you.
The project homepage is https://github.com/SineSwiper/Dist-Zilla-TravisCI.
The latest version of this module is available from the Comprehensive Perl Archive Network (CPAN). Visit http://www.perl.com/CPAN/ to find a CPAN site near you, or see https://metacpan.org/module/Dist::Zilla::TravisCI/.
Brendan Byrd <bbyrd@cpan.org>
This software is Copyright (c) 2014 by Brendan Byrd.
This is free software, licensed under:
The Artistic License 2.0 (GPL Compatible)
To install Dist::Zilla::Role::TravisYML, copy and paste the appropriate command in to your terminal.
cpanm
cpanm Dist::Zilla::Role::TravisYML
CPAN shell
perl -MCPAN -e shell install Dist::Zilla::Role::TravisYML
For more information on module installation, please visit the detailed CPAN module installation guide.