Saturday, July 13, 2013

Travis CI: a chink in the armor

My employer is considering Travis CI and I have input to our process, so a couple of weeks ago I decided to experiment using an open source project.

I ran into a roadblock when I initially forked a project and tried to add it to my Travis CI builds: the variables in the config file were all wrong. But even worse, the variables were all encrypted, so there was no way to learn by example from the original settings let alone compare and contrast them to a user guide or reference.

Yet this is just an opportunity to check out the Travis CI community. So I posted to a Google Group, travis-ci:
I am just starting with Travis-CI and a little confused about the use of encrypted variables in a .travis.yml file. 

Suppose a repo is forked on Github, which contains a few dozen - secure: entries, 
and that there is no record of the names of the variables that have been encrypted.

Is it possible to determine the variables' names (or really, the role they play in the build), 
for the purpose of updating to whatever makes sense relative to the forked repo?

Sorry for the newbie question, but it seems like it would be pretty hard to carry forward a sane config unless the original variables were documented in some way. 
But, to quote The Walrus and The Carpenter, answer came there none. 

Travis CI should take note: a community that doesn't know how to respond to a recommended practice of throwing away source opens a window of opportunity for a responsive competitor to offer a better alternative even if it is just by way of a best practice. 

The pragmatic answer could be "we don't know" or "we are ignoring you because we don't know you," or possibly some combination thereof, but I'm inclined to believe the pragmatic answer is "no".   

Bottom line: It is a rather insane practice to rely on fully encrypted code as if it were source.  The config file isn't source - it is a build artifact of a source template, parameterized by instance variables. It is the latter that should be encrypted; the former is needed in order to reproduce the config file artifact within a different context (like a fork).