Greetings from cirrus-run author

[Andrea Bolognani]

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