Branches master protégées ?

Je lisais bien que @Loiseau2nuit parlait de pusher mais non de force pusher, c’est sympa ces jeux de devinettes :stuck_out_tongue:

1 « J'aime »

Bah, peut-être que c’est son repo local qui était décalé, peut-être que c’est un autre projet dans spip-contrib-extensions, mais perçu comme « perso »… En soit, quand on est tout seul a commit, pas forcément besoin de branche, de PRs, etc. : C’est un projet perso, quoi …

Je voulais dire : les rôles « maintainer » et « developper » ont été attribués de manière horizontale, à l’origine (création du gitlab).

Je suis mainteneur partout, sur toutes les orgas, comme une 15aine de personnes (team ?) tel que le gitlab a été initié.

Oui, c’est ce qui semble hérité de la config globale.

Oui, cf plus haut.

Mais, sur ddev par exemple, je ne peux pas pusher sur master :

mais j’ai comparé les réglages de branches protégée et de droits avec plusieurs autres dépôts au hasard et c’est différent sur ddev. Peut être j’avais modifié moi même, je ne sais plus.
Je suis repassé au réglage par défaut (config globale)

Bon, et je suis ok sur le fait de ne jamais autoriser de push --force sur master.
On est d’accords là dessus.

Tu es admin. Comme 13 autres personnes, sans compter les Bots.

Et on ne pourrait pas devenir soi même automatiquement maintainer de son dépôt (i.e. projet) quand on en crée un nouveau dans une des orgas spip-contrib-* ?

Ce serait l’idéal non ?
A partir de là, si on est maintainer de son dépot, on peut assigner d’autres maintainers, gérer sa config etc.

Ce que je disais là :

mais peut être pas simple à mettre en place ?

Oui bien sûr, je parlais de rôles en termes de droit gitlab (Developers / Maintainers).

Non.

Faut être owner pour ça, d’un groupe git, par exemple, avec d’autres personnes, ça fait un collège …

ça détourne complètement la mécanique de base pour refaire la même chose, avec des scripts à maintenir, des plugins en ruby … pour arriver à la mécanique de base, en plus compliqué …

Moi je suis pas chaud. :slight_smile:

Être admin permet d’outrepasser certains droits/certaines permissions, sauf les trucs sur les users, le transfert git, les imports et d’autres trucs dont on ne se sert pas …