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 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
