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
>
signature.asc
Description: PGP signature
