Branches master protégées ?

Dev
#9

Je pense à l’inverse qu’on devrait trouver un fonctionnement sécurisant qui convient à l’immense majorité des cas, et qu’il ne faut PAS partir sur des tonnes d’orga avec des fonctionnements différents.

Que de manière hyper ponctuelle pour tel projet précis super sensible (genre plugin Bank) on ait besoin d’un autre fonctionnement encore plus bloquant ok. Mais ça devrait rester des cas super rares.

Dans SPIP on a toujours eu un fonctionnement collégial et communiste, ou le plus possible de gens ont les mêmes droits, et où le fonctionnement global est le même partout. Contrairement à Github où on individualise tout, le libéralisme codal (et la main invisible fera magiquement que l’addition de tous les individualismes augmentera l’innovation et la croissance).

Donc qu’on renforce la sécurité en ajoutant des étapes (PR etc) avant de pouvoir intégrer, ça c’est super, vraiment. Mais de mon avis, pas en poussant volontairement à l’éclatement en plein d’espaces persos séparés avec des règles différentes. On n’est pas chez les libertariens ici.

1 « J'aime »
Quand on est coincé pour faire un truc sur git, on fait quoi ?
#10

Je pense aussi, pour les même raisons.

1 « J'aime »
#11

J’ai regardé, tu es bien Maintenair dans le groupe spip-contrib-outils cf Membres du groupe · spip-contrib-outils · GitLab tu peux donc pusher. Mais, comme on peut le voir dans la capture d’écran que tu postes, la case « Autoriser à forcer les poussées » n’est pas cochée, voilà pourquoi ton push force ne passe pas.

Je ne pense pas que ça soit une bonne idée d’autoriser le push force sur les branches protégées de manière globale, mais c’est possible de le faire au cas par cas exemple avec ddev ici https://git.spip.net/spip-contrib-outils/ddev/-/settings/repository

image
image1169×414 48.7 KB

#12

Si je ne me trompe pas, les accès au dépôts sont définis par défaut à partir du groupe de l’organisation dans lequel le dépôt est créé. Exemple avec Membres · spip-contrib-extensions / dumpauto · GitLab où on voit bien les 529 membres du groupe Connexion · GitLab

Or, tous les membres du groupe n’ont pas les même rôles, certaines personnes sont maintenair et d’autres developper (ce qui ne permet donc pas à tout le monde de fusionner).

Non justement, ça peut être appliqué de manière différente dans chaque groupe.

  1. semble en place
  2. on retire donc le droit de push aux « developpers » ? Ça peut avoir un impact vu ce que je dis plus haut.
  3. est en place
  4. comme je le disais dans mon message précédent, je ne suis pas chaud pour appliquer ça globalement, ça retire une bonne partie de l’intérêt des branches protégées
#13

C’est sur quel repo ? (histoire qu’on y jette un œil)

#14

admin/users/l.oiseau2nuit/projects en bas, t’as les projets perso

#15

Hello,
Pas vraiment au niveau de compétences de vos échanges mais il se trouve que c’est moi qui ait créé le repo pris en exemple spip-contrib-extensions / dumpauto · GitLab
J’y suis effectivement developper, ce qui ne m’empêche pas (heureusement !) d’y faire mes push. Par contre j’ai constaté que ne n’avais pass accès au Settings anecdotiquement pour y mettre un avatar. Sans être vraiment gênant, c’est un effet de bord de mon rôle developer dans cette organisation ?
Merci de vos avis !

#16

C’est la différence entre créer un projet dans son propre « namespace » (on est owner) et créer un projet dans un groupe pré-existant ou les rôles sont pré-déterminés (et là, c’est variable).

#17

Ok, c’est clair. Il me semblait que j’y avais accès précédemment sous Gitea, mais peut-être les règles était différentes.
Merci pour l’explication. :slight_smile:

#18

J’en doute, mais Gitea, la migration GitLab, le nombre d’admins des plates-formes, ce qu’on pouvait faire, peut faire aujourd’hui et ne pas faire … ça rend les choses très compliquées à expliquer. De plus, bien que technique, c’est sujet à interprétations, pas bien maîtrisé par assez de gens : On finit par en dire n’importe quoi. :wink:

2 « J'aime »
#19

@Loiseau2nuit donc sur tes deux repos persos tu es owner, le rôle le plus haut, tu peux donc « normalement » tout y faire cf Connexion · GitLab & Membres · Loiseau2nuit / zktx-kore · GitLab

Quand tu dis ça, que tentes-tu de faire précisément (quelle commande, dans quel contexte), et quelle est l’erreur renvoyée par la forge ?

#20

Sa branche par défaut (master chez lui) n’autorise pas le force push, c’est tout. :slight_smile:

#21

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 »
#22

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 …

#23

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é.

image
image1250×750 74.8 KB

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 :

image
image1126×141 15.6 KB

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.

#24

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

#25

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 ?

#26

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

#27

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:

Plugins incompatibles avec SPIP4.1 ou plus
#28

Ê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 …