[Mesa-dev] Mesa GitLab <-> AppVeyor integration

[Daniel Stone]

Hi,

On Wed, 28 Aug 2019 at 11:18, Michel Dänzer <michel at daenzer.net> wrote:
> On 2019-08-28 3:08 a.m., Eric Engestrom wrote:
> > On Tuesday, 2019-08-27 13:31:22 +0000, Jose Fonseca wrote:
> >> Appveyor seems to be building other MR 1781:
> >>
> >>   https://ci.appveyor.com/project/mesa3d/mesa-re1yd/builds/26989425
> >>   https://ci.appveyor.com/project/mesa3d/mesa-re1yd/history
> >>   https://gitlab.freedesktop.org/eric/mesa/pipelines/59190
> >
> > You shouldn't take my MRs as an example for this, as I've set up the
> > hook on my account, so my MRs always get picked up by appveyor :)
>
> Yeah, the external integration settings are per GitLab project, and
> pre-merge CI pipelines for MRs run in the source project context, so the
> appveyor integration would need to be set up in each forked project used
> for MRs.
>
> This is a bit unfortunate, as it means the CI pipeline which runs (in
> the main project context) after an MR is merged could fail at the
> appveyor step, even if the pre-merge pipeline passed.
>
> Not sure what can be done about this though, other than requiring forked
> projects used for MRs to set up the appveyor integration as well.

To be honest, given the relative immaturity of external-job reporting,
and some of the problems reported in #freedesktop for NetworkManager
using it, I would probably suggest not using it.

For Panfrost CI, which executes on an external system (LAVA), we
create a new job in the GitLab CI pipeline with the 'idle-jobs' tag,
which submits an HTTP request to LAVA to schedule the job, then sits
waiting for it to report results and logs back. The 'idle-jobs' runner
can do something like 64 concurrent jobs, as it's supposed to only be
used for things like this.

That might help with some of the flakiness, and bring the result
reporting in line with the rest of execution.

Cheers,
Daniel