Monday, January 18
travis ci and perl modules
I just spent a little time cleaning up the relationship between this site and Display.pm, the Perl module which renders most of it.
Along the way, I noticed that I’d signed up for a Travis CI account at some point, and it was attempting to run tests when I pushed to the Display.pm repo.
The deal with Travis is that you include a
.travis.yml file in your project’s
root, and it will try to follow instructions to check out your code and run any
tests you’ve defined, then squawk at you if they fail. It also provides those
little build status badges you see all over GitHub these
days. After reading Building a Perl Project, I wound up with
language: perl perl: - "5.22" - "5.14"
After that, it took me a half dozen tries to figure out why the tests were failing and make them genuinely self-contained, but lo, they pass now.
This was probably a lot easier because I’m already using Module::Build. I’m years and years out of touch with the Perl ecosystem, so I don’t know if Module::Build is still the thing to use, or if I’m supposed to have moved on to something shinier by now. It still seems to work pretty well, at least for my trivial needs.
Something I continue to appreciate about Perl, 15+ years after I first started spending time with it, is that I come back to things like this and usually find that they still work, are still documented, etc. This particular kind of durability seems, if anything, to have decreased dramatically in the tools that dominate now. It’s odd to find it so much more often in projects built on Perl, C, shell—even sometimes PHP!—than in the space of the languages, libraries, and frameworks considered acceptably modern for most projects.
Well, ok, not odd. But certainly striking.