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