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

Patrick Steinhardt [off-list ref] writes:

quoted

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