[Mesa-dev] Gitlab migration

[Mark Janes]

Daniel Stone <daniel at fooishbar.org> writes:

> On 26 May 2018 at 00:47, Mark Janes <mark.a.janes at intel.com> wrote:
>
>> I am eager to make Intel CI results more visible.  Can I push our
>> artifacts to an fd.o directory, and have GitLab display them to users as
>> if the build ran on fd.o?  A typical build produces ~500MB of junit test
>> output with ~4M results.
>
> Not currently, though it is on their radar:
> https://gitlab.com/gitlab-org/gitlab-ce/issues/17081
>
> Even if it were though, I don't think parsing a 500MB XML file
> server-side is a particularly good idea; same goes for Piglit's JSON,
> which is nicely human readable but far too verbose to be usable at
> scale. Think about scaling it out to the hundreds of projects (with
> however many repos) hosted by fd.o as a whole; all the forks thereof,
> the platforms and configurations they care about, and the number of
> developers and submissions. Even if we write off the 1.5 petabytes
> required to store results from this year's Mesa commits (ignoring
> pre-commit submissions) as workable, the server load to parse and
> display those results is just not workable for a large public service.

The files would be much smaller without the XML formatting.  Jenkins
parses the XML server-side whenever the website needs to display
results, which is why their implementation is not scalable.

We need something like Android's Cherry tool that stores results in a
database, and displays them to users:

  https://android.googlesource.com/platform/external/cherry

No one here has looked into how scalable that implementation is.  If
anyone has suggestions on how to provide really large test sets in a web
ui, I'm eager to get advice.

I would like to get *something* like this hosted externally, so
developers can get more out of our CI.

> There are some other things we could do though, such as:
>   - share common build configurations, build those for MRs and commits
> providing full feedback to developers for build errors in various
> configurations, and expose them (for a limited time) as downloadable
> artifacts
>   - have Intel Jenkins reuse those builds in order to run its various
> test suites on real hardware
>   - accept and display summary results (e.g. 'all tests successful' or
> a note of which tests regressed, etc)
>   - a link to download a reasonably-compressed result set stored as an
> artifact (e.g. the last 10MB results.tar.xz I got mailed back from the
> Intel CI is fine)
>
> Does that sound like something reasonable to aim for?

Maybe?  I'm not sure how valuable it is to share compiled binaries
between 2 systems.  Compiling is nearly free for us, but our external
network connection is not as good as I'd like.

We can publish matching test artifacts to your system if you think that
would help.

IMO the tarball is not very useful compared to a mature test result UI.
In particular, viewing the history of test results for a mesa branch is
a common use case for figuring out when regressions were introduced.
Unfortunately, we need a scalable implementation...