freedesktop - Aug 2018 - [fdo] Postmortem: July 17th GitLab outage

Marek Olšák <maraeo at gmail.com> writes:
> We can also save space by using the main repo for private branches,
> e.g. my branches would be in refs/heads/mareko/*.
It sounds like gitlab is not going to have this fixed very soon:

https://gitlab.com/gitlab-org/gitlab-ce/issues/23029

I think this is an interesting idea.  It would increase exposure of Mesa
developers to what each other is doing, without everyone needing to go
star each other's repos.  I think Mesa has been a little too cautious
with branches in the main repo -- we very rarely push branches, and
we're definitely bad at deleting those old branch heads once they're no
longer relevant as branches for development.  On the other hand, I'm not
sure everyone wants to see every weird unfinished branch I have, and a
personal repo is nice for hanging on to those.

Once we have gitlab CI hooked up (hopefully in the next week or so), I
want developers to be able to push to gitlab and have CI go through the
patch, before they actually submit to the ML.  If we're pushing to
branches on origin, that could potentially be a lot of mailing list
spam.  I'd want some sort of solution for that before we start telling
people to just put their stuff in user branches on the central repo
instead of personal forks.  People can also be a lot more cavalier with
git push personalrepo +branch than I'd like to have them be with git
push origin +branch.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/freedesktop/attachments/20180801/858bf040/attachment.sig>

On Wed, 1 Aug 2018 at 20:00, Eric Anholt <eric at anholt.net>
wrote:
> Marek Olšák <maraeo at gmail.com> writes:
> > We can also save space by using the main repo for private branches,
> > e.g. my branches would be in refs/heads/mareko/*.
>
> It sounds like gitlab is not going to have this fixed very soon:
>
> https://gitlab.com/gitlab-org/gitlab-ce/issues/23029
To be honest I'm not really concerned about that. Space is
surprisingly cheap, and in a couple of weeks or so we should be able
to use transparently-resizable volumes with either no downtime or
~5min.
> Once we have gitlab CI hooked up (hopefully in the next week or so), I
> want developers to be able to push to gitlab and have CI go through the
> patch, before they actually submit to the ML.  If we're pushing to
> branches on origin, that could potentially be a lot of mailing list
> spam.  I'd want some sort of solution for that before we start telling
> people to just put their stuff in user branches on the central repo
> instead of personal forks.
If you give me a blacklist or whitelist of branches (e.g. 'blacklist
wip/*') I can fix the hook easily.
> People can also be a lot more cavalier with
> git push personalrepo +branch than I'd like to have them be with git
> push origin +branch.
You can control this:
https://docs.gitlab.com/ee/user/project/protected_branches.html