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é <berra...@redhat.com> wrote: >>>> On Thu, Aug 12 2021, Daniel P. Berrangé <berra...@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
