New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add initial Travis-CI configuration #4

Open
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
1 participant
@paultcochrane

paultcochrane commented Sep 7, 2018

This patch implements changes necessary for the dist to be automatically tested on the Travis continuous integration infrastructure.

I'm not 100% happy with this patch as it is (for a few reasons), so please consider this as a starting point for a discussion for how the patch should look in the end: I'm more than happy to update and resubmit the PR after your feedback so that, in the end, the merge for you is as simple and painless as possible.

The main thing I'm not happy about is the number of changes I had to make to the dist.ini in order for this to work in my dev environment and then on Travis. I'm fairly sure that I'm missing something, so please forgive my ignorance.

Here are my notes:

  • it turned out that it wasn't possible to run dzil listdeps --author --missing without specifying the license and copyright_holder fields in dist.ini. It seems that this information is added later as part of a plugin in the author bundle, however it's not clear how that should be set up for someone in a different development environment (e.g. on Travis). Hence the tags were added after the dist name. What would be a more elegant solution to this issue?
  • it was also necessary to install Pod::Weaver::PluginBundle::Author::PERLANCAR before dzil test could be run. This issue could be fixed by adding the line ; authordep Pod::Weaver::PluginBundle::Author::PERLANCAR to the dist.ini (as is recommended for Pod::Weaver plugin dependencies). What I'm not sure about is the location of this line in the dist.ini. At present it's at the end, but maybe you want it closer to the beginning somewhere as that may be more relevant, so that its presence becomes more obvious. What would you like? Or is it ok at the end?
  • the StaticInstall plugin is on by default in the author bundle and this causes dzil test to fail, since it considers the dist to be ineligible for a static installation. The only way I could find to get dzil test to run (without adding a new dependency) was to use @Filter to remove StaticInstall from the author bundle. This enabled the test suite to at least run. Is there a more elegant way to disable StaticInstall in a fresh development environment?
  • the next issue was that the test suite always runs the author tests, even though they aren't specified in the dzil test call. I haven't been able to work out which plugin is responsible for this behaviour, so I haven't been able to turn it off. This is the reason why I can't deliver a Travis config with passing tests (which is my usual goal with such PRs). Is it possible to turn off the author tests, at least temporarily? Presently there are several perlcritic-related tests which cause the test suite to fail when run this way. Or am I just being silly and should run dist build followed by perl Makefile.PL etc?
  • for some reason the required minimum version for CPAN::Meta::Prereqs couldn't be determined in the dzil authordeps and dzil listdeps steps and in order to avoid spurious failures due to an insufficient version, this module is installed explicitly before the other *deps calls.
  • it's only possible to test from Perl 5.14 onwards since Dist::Zilla requires this as a minimum version. Incidentally, Pod::Weaver::Plugin::EnsureUniqueSections requires at least 5.12, but this is covered by the Dist::Zilla minimum version dependency.
  • it was necessary to create an empty ~/pmversions.ini file for dzil test to run. Is there some way one could avoid this? Perhaps one could put the pmversions file in the dist's main directory rather than the user's home directory? Or perhaps is it possible to avoid a total failure if the user doesn't have such a file? Just wondering what the most elegant solution would be in this case.

I think that's about it. Sorry for the long list! Once these points are cleared up, perhaps I could submit a CONTRIBUTING.md file so that future contributors know what they need to have in their local environment before trying to build, test and extend the dist.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment