Greetings from cirrus-run author
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. 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. 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? Thank you very much for using cirrus-run! You've made me feel warm and fuzzy! [1]: https://github.com/sio/cirrus-run/issues/3
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
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
On Thu, Jul 30, 2020 at 03:59:17PM +0200, Pavel Hrdina wrote:
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.
Oh, so Cirrus CI automatically re-created the job, and cirrus-run isn't able to detect this re-created job ? Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Thu, 2020-07-30 at 15:59 +0200, Pavel Hrdina wrote:
On Thu, Jul 30, 2020 at 03:04:37PM +0200, Andrea Bolognani wrote:
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...
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.
That makes sense. The Web UI provides links to all other instances of a certain task when it gets rescheduled, however, so I wonder whether the API also exposes that information and whether cirrus-run would be able to "chase" after the task by using it... They both belong to the same build after all, so it should be possible to correlate them. -- Andrea Bolognani / Red Hat / Virtualization
On 30 July 2020 17:17:56 GMT+03:00, Andrea Bolognani wrote:
That makes sense. The Web UI provides links to all other instances of a certain task when it gets rescheduled, however, so I wonder whether the API also exposes that information and whether cirrus-run would be able to "chase" after the task by using it... They both belong to the same build after all, so it should be possible to correlate them.
I've created an issue with some explanation: https://github.com/sio/cirrus-run/issues/4 Currently cirrus-run is tracking the status for the whole build, and I'd really like to know what build status looks like while task is being rescheduled. I know it's not feasible to run all CI in verbose mode, so I do not really expect catch such case with '-v' on. Tracking build status by individual tasks would be tricky: some task failures do not lead to build failure (like in this case) while most of them do. I think a simple timeout & recheck should work.
On Thu, Jul 30, 2020 at 01:58:28PM +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.
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.
FWIW, I don't think we need to have "live" logs while the job is running. That's more of a nice to have category. What I was mostly interested in was to simply pull over the log output once the job completes/fails. Essentially so that when someone goes to browse the job results upon completion of the GitLab pipeline, all the log data is viewable from the same place. This would also mean that the GitLab emails sent on failure would be able to include the last 20 lines of the real build failure. So possibly that is as simple as just figuring out the URL where Cirrus CI stores the log and just pulling down its contents. May not really involve the Cirrus CI API at all. In fact we could probably do that in libvirt's GitLab CI rules, but if cirrus-run wants to provide this kind of feature it'd obviously make it more accessible to a wider userbase. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
participants (4)
-
Andrea Bolognani -
Daniel P. Berrangé -
Pavel Hrdina -
Vitaly Potyarkin