<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, May 25, 2018 at 4:47 PM, Mark Janes <span dir="ltr"><<a href="mailto:mark.a.janes@intel.com" target="_blank">mark.a.janes@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Daniel Stone <<a href="mailto:daniel@fooishbar.org">daniel@fooishbar.org</a>> writes:<span class=""></span><br><span class=""></span></div></div><span class="">
> GitLab CI fixes all of these things. Pipelines are strongly and<br>
> directly correlated with commits in repositories, though you can also<br>
> trigger them manually or on a schedule. Permissions are that of the<br>
> repository, and just like Travis, people can fork and work on CI<br>
> improvements in their own sandbox without impacting anything else. The<br>
> job configuration is in relatively clean YAML, and it strongly<br>
> suggests idiomatic form rather than a forest of thousands of<br>
> unmaintained plugins.<br>
><br>
> Jobs get run in clean containers, rather than special unicorn workers<br>
> pre-configured just so, meaning that the builds are totally<br>
> reproducible locally and you can use whatever build dependencies you<br>
> want without having to bug the admins to install LLVM in some<br>
> particular chroot. Those containers can be stored in a registry<br>
> attached to the project, with their own lifetime/ownership/etc<br>
> tracking. Jenkins can use Docker if you have an external registry, but<br>
> again this requires setting up external authentication and<br>
> permissions, not to mention that there's no lifetime/ownership/expiry<br>
> tracking, so you have to write more special admin cronjob scripts to<br>
> clean up old images in the registry.<br>
<br>
</span>GitLab may be perfectly suitable for CI, but please do not select Mesa<br>
dev infrastructure based on CI features.<br>
<br>
Any Mesa CI needs to trigger from multiple projects: drm, dEQP, Piglit,<br>
VulkanCTS, SPIRV-Tools, crucible, glslang.  They are not all going to be<br>
in GitLab.<br>
<br>
The cart (CI) follows the horse (upstream development process).  CI<br>
automation is cheap and flexible, and can easily adapt to changes in the<br>
driver implementation / dev process.<span class=""><br></span></blockquote><div><br></div><div>I think part of the difficulty in this discussion is something you referenced in the second paragraph above.  The type of CI we do in our Jenkins system is in a different domain than the type of CI supported by the likes of gitlab.  The CI we do in our lab is more along the lines of integration testing where multiple components all have to come together whereas the gitlab CI framework is more intended to support single-project unit testing.  The gitlab CI system also does not scale nearly well enough to handle the kind of testing that we need to do.  The gitlab CI hooks would work fairly well for building the website, running some build tests, and maybe make check but it will never be a replacement for the Jenkins system we have in our lab.  They're a useful feature (that's a good thing!) but certainly not a replacement for what we have today.  I'm sorry if I implied that it would;  I certainly did not intend to.<br></div></div></div></div>