Greetings from cirrus-run author

[Pavel Hrdina]

On Thu, Jul 30, 2020 at 03:04:37PM +0200, Andrea Bolognani wrote:
> On Thu, 2020-07-30 at 13:58 +0300, Vitaly Potyarkin wrote:
> > Hello, my name is Vitaly - I'm the author of cirrus-run.
> > 
> > I was amazed to see that a project of such importance and scale uses the
> > tool I created! Thank you very much! I never expected it to receive much
> > recognition outside of a few random hobbyists, after all I wrote it just
> > to cheap out on CI runs for a personal project.
> 
> Hi Vitaly!
> 
> I was meaning to get in touch with you to thank you for creating
> cirrus-run and tell you how useful this clever little tool of yours
> has proven to be, but it looks like you beat me to the punch :)
> 
> We've adopted it a couple of months ago, and we've been extremely
> pleased with it so far. We're planning to roll out its use to more
> repositories over time, but we just haven't gotten around to it quite
> yet.
> 
> > I noticed that you expressed a wish to have full CI log fetched and
> > displayed on stdout. I agree that it would be a nice feature to have,
> > and I've planned to make it like that from the beginning, but the
> > GraphQL query for that was not straightforward at all and I've settled
> > for what we have now. I added an issue [1] in cirrus-run repo and will try
> > to return to that sometime.
> 
> Thanks, I'll subscribe to the issue.
> 
> Since I have your attention, I'll also report the only issue we've
> encountered so far that might be a genuine bug in cirrus-run. If you
> look at this recent pipeline
> 
>   https://gitlab.com/libvirt/libvirt/-/pipelines/170028119
> 
> you'll see that the x86-freebsd-12-build job has failed; however if
> you look at the corresponding Cirrus CI job
> 
>   https://cirrus-ci.com/build/6133607741784064
> 
> you'll notice that it has completed successfully. We've seen this
> happen about once a week on average. It's as if cirrus-run somehow
> lost track of the status of the Cirrus CI job...
> 
> Unfortunately I haven't had time to dig further, but if there's any
> information that I could provide to help you figure out what's going
> on please just ask.

I'm not sure if there is anything that cirrus-run can do about it.
Depends on the cirrus-ci API. In the case that you've mentioned the
issue is that the job was rescheduled on cirrus-ci. This is most likely
the original job that was terminated:

    https://cirrus-ci.com/task/5722023156514816

and the job that caused cirrus-run to report failed job.

Pavel

> 
> > I also noticed you've implemented some custom templating mechanics with
> > @VARIABLES@ and sed in build.yml - why did you choose to go that way
> > instead of templating with Jinja? Are there some underlying issues?
> 
> Not issues per se, the Jinja templating worked fine. However, we have
> to be very careful with how we set $PATH in the GitLab CI job
> environment (obviously), hence the
> 
>   sed -e "s|[@]PATH@|$PATH_EXTRA${PATH_EXTRA:+:}\$PATH|g"
> 
> We could use a different variable name, but then the Cirrus CI job
> template would look like
> 
>   env:
>     PATH: "{{ TOTALLY_NOT_PATH }}"
> 
> which looks slightly less nice.
> 
> We could also adopt a hybrid approach, where only $PATH is handled
> with sed and everything else takes advantage of the native Jinja
> templating capabilities of cirrus-run, but I feel like that would be
> less maintainable than having all substitution happen in a single
> place.
> 
> > Thank you very much for using cirrus-run! You've made me feel warm and
> > fuzzy!
> 
> Thank you for creating it! You've helped make our CI infrastructure
> much better :)
> 
> -- 
> Andrea Bolognani / Red Hat / Virtualization
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20200730/cfdf17be/attachment-0001.sig>