Re: [PATCH 0/3] fixing expensive http test timeouts

[Junio C Hamano <gitster@pobox.com>]

Patrick Steinhardt <ps@pks.im> writes:

>> pushes only to "cast in stone" branches.  If there are other
>> branches that deserve to be tested with TEST_LONG upon other events
>> that the existing GitHub Actions CI does not trigger, it may be good
>> to have GitLab CI cover them, perhaps?
>
> I'm a bit hesitant to do such a split, mostly because the canonical
> source of truth that the project typically uses is GitHub's CI. So I
> want us at GitLab to be able to catch the same issues that GitHub would
> flag. And if GitLab's CI stopped detecting everything that GitHub does,
> then the result would likely be that we often create merge requests on
> both platforms, which would only result in more wasted resources.

I didn't suggest splitting them into two circles that overlap but
each with area only it covers, though.  GitLab's coverage can be
superset to GitHub's and that would satify what I suggested.

FWIW, I do not consider GitHub's CI "the canonical source" at all.
It is a very handy service to use to check how well we are doing,
but from time to time it has its own hiccups ;-).

What can we do to make the visibility of GitLab's CI more prominent?

I know where the CI jobs that are triggered when I push out the
integration branches are found at GitHub's website[*], but I do not
think I know the corresponding one at GitLab, for example, and I
think that is a shame.


[Footnote]
 *1* I just made https://tinyurl.com/github-gitci that points at
     https://github.com/git/git/actions/workflows/main.yml?query=event%3Apush+actor%3Agitster