Re: [PATCH 2/2] gitlab: don't run CI jobs by default on push to user forks

[Philippe Mathieu-Daudé]

On 8/16/21 2:01 PM, Daniel P. Berrangé wrote:
> On Mon, Aug 16, 2021 at 01:47:08PM +0200, Cornelia Huck wrote:
>> On Mon, Aug 16 2021, Daniel P. Berrangé <berrange@redhat.com> wrote:
>>>> On Thu, Aug 12 2021, Daniel P. Berrangé <berrange@redhat.com> wrote:

>>> When I'm working on changing gitlab CI rules, then I burn loads of
>>> minutes which is especially troubling - limited CI minutes will make
>>> it very hard for me to debug future CI rule changes :-(
>>
>> I hope that will not make gitlab CI a complete non-starter -- if you
>> cannot easily debug a test case that is failing, it's mostly
>> useless. We've seen too many cases where a failure could not be
>> reproduced when the test case was running locally.
> 
> One of the best things about GitLab compared to what we had with
> Travis is that the build environment is 100% container based (until
> Cleber's custom runners arrived).  This meant that when something
> does fail in GitLab, you can pull the container image down from
> the gitlab registry and run the build locally. You still have
> differences due to hardware or CPUs resources, but its a hell of
> alot easier to reproduce than before. This is good enough for most
> contributors in general, but not for the CI maintainers, who need
> to debug especially the CI system as it exists on GitLab.

FWIW we could do that with Travis-CI too using:

 $ make docker-test-build@travis