> In any case, you can enable salsa CI on your personal fork to track this.
Hmmm, I think we should not propagate personal forks. I'm afraid that
some fork might feature interesting commits but will be lost somewhere.
So I'd prefer to have salsa CI activated on the main med-team
repository.
Sure. And this reminds me again of the proposal to talk to salsa admins to enable it by default - after some brainstorming for choosing a default salsa-ci.yml ofcourse.
This will:
a) Directly help mitigate these problems to track such issues
b) Improve overall quality of packages
c) Help _sometimes_ to rely on CI if the build is very time+resource consuming
We are currently manually enabling CI on several repos, and if we do it several number of times, we might end up breaking salsa ourselves -- thoughts?
> I'm not sure what "couldn't push my changes because it is on a protected
> branch" means here. You should be able to push unless you aren't trying to
> force-push.
I observed from time to time that master branch is marked "protected"
and I have no explanation at all and this is extremely annoying since it
might scare away newcomers.
Protecting the master branch is an ideal thing to do since this doesn't allow force pushing -- if it wasn't protected, it'd be easy for a new comer who's not very well versed
with git to mistakenly mess things up.
My "cure" is to simply set those people who
are affected to "Maintainer" status (which seems to enable also pushing
to protected branches).
This is some mystery which I've not known the answer to. I remember not being able to push stuff to science + nim team w/o "maintainer" access bump
May be we should simply run a script to unprotect
all master branches ... and find out why this might happen at all.
That can have repercussions (see the reply above) -- I'd recommend not doing that
> If you aren't force-pushing, then you need better access than developer
> probably for this one. I just granted you maintainer access for this repo,
> try pushing once.
I've set general maintainer access. I think if we want to enable people
to create new repositories all should get this status. I fail to see any
sense in different levels of membership.
Probably the rationale is that someone set as "maintainer" can change protected branch settings + CI vars et. al -- this can end up causing potential damage if accidentally a spammer gets such an access.
But I suppose we assume good intent most of the times, and it should generally be safe. (It's quite OK in Shruti's case, definitely)
Ofcourse, apologies if I said something wrong here :-)
Nilesh