[Pdx-pm] November meeting?

Thu Nov 8 11:32:24 PST 2012

Howdy,

Awesome! So glad my stream-of-consciousness description was useful.

As for your wishlist:

1) Yes, Travis only does Ubuntu Linux and I don't think they plan on doing
others, at least not for free.

If you want access to lots of crazy systems, I recommend the GCC compile
farm [0]. They are very friendly and give out access to any reasonable
request.

2) This *is* (mostly) possible by using environment variables, which you
can use to tell your code to run different kinds of tests and things like
that. If you bring this up in the meeting, I can try to answer some
specific questions.

Duke

[0] http://gcc.gnu.org/wiki/CompileFarm

On Thu, Nov 8, 2012 at 10:11 AM, Dana Jacobsen <dana.jacobsen at gmail.com>wrote:

> My Lord "Duke", and others,
>
>   Based on these instructions, I set up Travis CI on a couple of my repos
> in ~20 minutes -- much of that waiting for it to run before realizing it
> wanted a commit to trigger builds.  I found it started a build within a few
> seconds of my running 'git push' on my box (admittedly this was done in the
> middle of the night) and had final results within a few minutes.
>
> Very nice, very easy, and free.  It also found an issue with one of my new
> functions that I was able to quickly fix -- which definitely made it worth
> it.  I'm looking forward to hearing more about it tonight.
>
> Some things I wish it had:
>
>   - a plethora of different build environments for occasional testing.
> 32-bit vs. 64-bit, something non-x86, a big-endian target, Ubuntu / CentOS
> / Solaris / BSD / etc., Perl with threads vs. without, something with a
> non-gcc compiler, etc.  These are the things that are hard for me to test
> in my environment and would be great to have run before waiting for the
> CPANTesters results.
>
>  - a method to indicate additional builds with different dependencies.
> That is, I'd like one build to run on the bare system.  Another after GMP
> loaded.  Another with an additional module.  I try to do this by hand on my
> systems, but it's tough to remember to do all the combinations and having
> it run by CI would be great (obviously I'd have to specify the
> combinations).  I can think of lots of examples of this -- Any::Moose,
> Class Accessors that get opportunistically used, various XS modules that
> get used if they exist, and so on.  I do a lot of that in my modules, and I
> normally test it by hand.
>
> It's possible it has some of these and I just don't know how to do it.  I
> also realize some people aren't as concerned about running on obscure
> systems, or their modules aren't brittle so it almost never matters -- XS
> modules doing bit twiddling, and anything relating to threading have been
> my biggest issues.  Lastly, I realize it's free so I'm getting far more
> than my money's worth already.  Perhaps at the meeting we can discuss other
> systems that might easily allow these.
>
>   Dana
>
>
>
> On Mon, Nov 5, 2012 at 8:18 PM, Jonathan "Duke" Leto <jonathan at leto.net>wrote:
>
>> Howdy,
>>
>> Travis CI *can* be this simple:
>>
>> 1) Log into Travis CI and flip the bit on the repo to add CI
>> 2) Put a .travis.yml file in your repo. Here is a relatively simple
>> example [0] suitable for most CPAN modules. This one that I wrote for
>> Parrot [1] does some whackier stuff and originally had to roll it's own
>> Perl dependency management.
>> 3) Commit and push .travis.yml
>>
>> If 1) doesn't work (maybe because it times out because you have too many
>> Github repos...), one can also use the Travis API key available in your
>> profile to enable Travis as a post-receive hook in the admin section of the
>> repo on Github. Step #1 automates this.
>>
>> Let the record show that I have helped write a CI system using Perl + Git
>> called Jitterbug :
>>
>> http://lumberjaph.net/jitterbug/
>>
>> That takes more work to setup, but is still useful for private repos. All
>> public repos on Github can use Travis for free, but you gotta pay cash
>> money for private repos.
>>
>> Have the appropriate amount of fun,
>>
>> Duke
>>
>> [0] https://github.com/leto/math--primality/blob/master/.travis.yml
>> [1] https://github.com/parrot/parrot/blob/master/.travis.yml
>>
>>
>> On Fri, Nov 2, 2012 at 3:16 PM, Eric Wilhelm <enobacon at gmail.com> wrote:
>>
>>> # from benh on Friday 02 November 2012:
>>> >Could be interesting, how does travis compare with CPANTS, how to set
>>> >up travis. Other tips/tricks/hooks and such.
>>>
>>> Live demo?  Sounds like fun.
>>>
>>> --Eric
>>> _______________________________________________
>>> Pdx-pm-list mailing list
>>> Pdx-pm-list at pm.org
>>> http://mail.pm.org/mailman/listinfo/pdx-pm-list
>>>
>>
>>
>>
>> --
>> Jonathan "Duke" Leto <jonathan at leto.net>
>> Leto Labs LLC http://labs.leto.net
>> 209.691.DUKE http://dukeleto.pl
>>
>> _______________________________________________
>> Pdx-pm-list mailing list
>> Pdx-pm-list at pm.org
>> http://mail.pm.org/mailman/listinfo/pdx-pm-list
>>
>
>

-- 
Jonathan "Duke" Leto <jonathan at leto.net>
Leto Labs LLC http://labs.leto.net
209.691.DUKE http://dukeleto.pl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/pdx-pm-list/attachments/20121108/d1d8676a/attachment.html>