[Zeek-Dev] maybe migrating Zeek CI from Travis to Cirrus

[Tim Wojtulewicz]

> On Dec 9, 2019, at 6:15 PM, Jon Siwek <jsiwek at corelight.com> wrote:
> 
> On Mon, Dec 9, 2019 at 3:05 PM Tim Wojtulewicz <tim at corelight.com> wrote:
> 
>> 1. Can we build arbitrary branches on Cirrus?
> 
> Yes, it's a bit awkward how you do it, but I guess better than Travis.
> In Cirrus, you can manually trigger an arbitrary branch, but like
> Travis, the default is to reject branches that are not whitelisted:
> 
> https://github.com/jsiwek/zeek/blob/94c4790610cf279157ecd536df144fadb83835c1/.cirrus.yml#L13-L16
> 
> But in Cirrus, you also get the option to override the .cirrus.yml
> directly in the web interface for manually triggering a branch.  So
> basically you can copy-paste the .cirrus.yml and remove the "only_if"
> lines, no temporary hacks needed to be committed into the branch
> itself.

That sounds reasonable enough. It just always bothered me having to do weird tricks with the actual branch to make it build.

> 
>> 2. Why move the Coverity build? Does it not offer a cron-like interface for running regular builds?
> 
> Didn't look like Cirrus has cron-like functionality yet, see
> https://github.com/cirruslabs/cirrus-ci-docs/issues/39
> 
> But also the Coverity build doesn't exactly fit the same mold as the
> other tasks.  If we didn't have any Coverity usage limitations (think
> it's 1 build per day?) and it was required to run on every new commit
> in `master`, then I'd say it would be ideal to have that ported into
> Cirrus, too, but since that's not the case, I don't have much
> preference where it runs except doesn't seem efficient to pay to
> bypass the 50 minute Travis time limit anymore just for doing the
> Coverity build if GitHub Actions has a free 6 hour time limit and also
> supports cron workflows.

I see your point there. A single GitHub action would be enough to do the single-platform build that we need for Coverity.

> 
>> 3. Can you move the travis-job script up into the ci directory instead of leaving it in testing?
> 
> Just to keep things a bit more organized while Travis is still being
> used in parallel with Cirrus? Sure, but eventually travis-job can get
> removed: rewrote/factored bits of that into the other ci/*.sh scripts
> for Cirrus to use.

That’s what I was thinking. It seems strange to have it out on an island by itself, even if it’s going to get removed eventually.