Gitea: Prise en charge des demandes d'extraction fédérées

_De @roblabla le 25 mai 2016 12:9_

Un peu lié : https://github.com/gogits/gogs/issues/2210

C'est la fonctionnalité numéro un pour un service Git hébergé personnel !
Ce serait encore mieux avec le #185 !

Cela pourrait également être intégré à l'intégration de git-appraise ?

Les propositions formelles

GitLab suit ce problème ici , alors peut-être pourriez-vous proposer un flux de travail rationalisé. Ils prévoient de mentionner la fonctionnalité lors de leur sommet.

@bkcsoft peut-être pouvez-vous aider à garder les spécifications GitLab suffisamment ouvertes pour permettre de fédérer également les relations publiques entre GitLab et Gitea ?

@strk est @bkcsoft affilié à GitLab ?

@strk Je pourrais l'orienter dans le sens d'un simple envoi de fichiers de correctifs entre serveurs (peut-être en utilisant des webhooks ?). C'est ce que je suggère que Gitea devrait faire aussi. Rend _vraiment_ facile de ne pas avoir à pousser/tirer entre les serveurs :)
@stevenroose Oui

Eh bien, il semble qu'ils pensent déjà ou utilisent git request-pull -p (qui envoie le correctif), donc il devrait être compatible avec toutes les plates-formes :slightly_smiliing_face:

Ils prévoient de mentionner la fonctionnalité lors de leur sommet.

https://gitlab.com/gitlab-org/gitlab-ce/issues/4013 est étiqueté comme moonshot , non attribué, pas de jalon et pas de MR en vue. Alors peut-être pas encore d'espoir :slightly_smiliing_face:

@bkcsoft Nous pourrions prendre les devants ici :) Si nous pouvons intégrer GitLab et GitHub, cela mettrait fin au verrouillage actuellement imposé par ces plates-formes

@bkcsoft Nous pourrions prendre les devants ici :) Si nous pouvons intégrer GitLab et GitHub, cela mettrait fin au verrouillage actuellement imposé par ces plates-formes

Je ne peux pas croire que GitHub veuille résoudre le problème de verrouillage :P

Non, mais si d'autres plateformes ouvrent la voie, les gens pourraient exiger qu'ils les suivent. Et les gens pourraient migrer :)

Un logiciel comme Gerrit permet en quelque sorte cela

@stevenroose avez-vous des références sur le support Gerrit ?

Si nous implémentons Gerrit, pourrions-nous inviter l'équipe de Golang à utiliser Gitea ? ??

@strk Avec Gerrit, vous empaquetez vos commits à l'aide de git-review et les poussez vers une certaine référence et cela apparaîtra dans Gerrit sous forme de revue de code. Pas besoin de créer une fourche Gerrit. Il n'utilise cependant pas git request-pull .

Vous auriez toujours besoin d'autorisations d'écriture sur le référentiel pour pousser ces
avis à la réf, non ?

Dans ce cas, le bit manquant serait toujours suivi
un repo différent détenant la référence d'examen ?

Ouais c'est différent. Il pousse des bits individuels avec une autorisation d'écriture.

Avec les PR fédérés, Gitea doit vérifier périodiquement (ou sur demande) la référence de l'agence pour de nouveaux changements.

AFAIK, git request-pull n'utilise pas du tout les commits git. Il génère simplement une liste de commits entre local et distant, et l'imprime sur stdout. Nous aurions besoin de spécifier un moyen d'envoyer ces modifications aux télécommandes/de les extraire des télécommandes

Git request-pull fait cependant partie de l'installation standard de git, contrairement à git appraise ou git review.

@roblabla Oui, le flux consisterait à enregistrer le git request-pull dans un fichier et à le télécharger (comme dans le passé, la soumission de correctifs fonctionnait). Ou soit entrez une URL vers une branche d'un référentiel distant afin que Gitea puisse mettre à jour le PR.

À moins que quelque chose ne me manque, git request-pull référence un commit spécifique,
tandis que les requêtes d'extraction github/gitea font référence à une branche (éventuellement en mouvement).

Voulons-nous que les requêtes fédérées suivent les branches plutôt que des commits spécifiques ?
Je pense que nous voulons un PR (fil de commentaires/discussion) pour suivre une branche.

il fait référence à des _commits_ spécifiques oui. Nous aurions donc besoin de récupérer continuellement les données 😒

Le mardi 20 décembre 2016 à 00:20:34 -0800, bkcsoft a écrit :

il fait référence à des _commits_ spécifiques oui. Nous aurions donc besoin de récupérer continuellement les données 😒

Nous ne pouvons récupérer de nouveaux commits que si nous avons une référence à un nom de branche,
qui n'est pas dans la sortie git request-pull . Donc, si nous voulons garder le
track-a-branch approche, nous ne pouvons pas nous fier à git request-pull .

Un créateur de relations publiques pourrait demander une URL distante et un nom de succursale, consultez le
branche distante localement, effectuez quelques vérifications (par exemple: refusez de créer PR avec
un grand nombre de changements) et créer le PR.

Ensuite, un bouton et un webhook pourraient être mis à disposition pour récupérer plus
commits, le cas échéant, à partir de la branche distante. Seul l'auteur des relations publiques doit être
étant donné la possibilité de demander des mises à jour. Placer un git hook sur sa fourchette
frapper le webhook de destination rendrait l'expérience de mise à jour plus fluide.

--strk;

Je suggérerais que lors de la création d'un PR en tant que compte invité, vous auriez un onglet avec "externe" ou "fédéré" ou tout ce qui a deux options :

1. un champ de saisie de texte pour une URL de succursale, avec un bouton "fetch" ou "test" peut-être pour vérifier l'accessibilité et la disponibilité du suivi

2. un champ de téléchargement de fichier pour télécharger un fichier .diff , .patch ou la sortie d'un git-request-pull ; cela pourrait aussi être une zone de texte

Dans ce dernier cas, une fois le PR créé, les utilisateurs devraient pouvoir écraser leur fichier précédent afin de modifier les commits dans le PR.

De plus, en cas d'indisponibilité des mises à jour automatiques des branches, vous pouvez demander à un utilisateur de déclencher manuellement une récupération. Dans presque tous les cas, les utilisateurs s'engagent dans une branche PR'ed exclusivement à la lumière de la validation, de sorte qu'ils peuvent simplement récupérer à tout moment pour mettre à jour la branche. (Prenez en compte que souvent, les mises à jour d'un commit sont dues à des commentaires dans le PR, donc la page est ouverte de toute façon.)

Comme l'a dit mon promoteur de thèse : « La vraie opposition à un changement ne vient pas des gens qui sont contre mais de ceux qui disent que ce n'est pas assez.

Je ne pense pas que cette fonctionnalité soit utile, vous pouvez ajouter deux télécommandes pour ce cas. par exemple branche github pour gh, master pour gogs, j'utilise les deux dans mon travail avec un référentiel. et git review est une autre chose. ne faites pas de grande fonctionnalité pour résoudre un petit problème.
de toute façon, les gogs se concentrent sur les petites entreprises ou l'auto-hébergement. pas pour le service cloud public.

@renothing Je ne pense pas que vous compreniez parfaitement la proposition. Cela n'a rien à voir avec la possibilité de comparer ou d'extraire le code de différentes sources distantes. Au lieu de cela, il s'agit de permettre aux gens de soumettre des demandes d'extraction ou des correctifs sans avoir à s'enregistrer sur votre système. Si je publie un logiciel sur mon instance Gitea, je souhaite que les autres puissent créer un PR sans les obliger à s'inscrire, à forker, à transmettre leurs modifications à mon instance, puis à créer un PR.

@stevenroose
comme je l'ai dit, c'est une scène assez peu demandée. pensez-y, combien de personnes ont besoin de fusionner un PR de l'essentiel ? Je ne pense pas qu'il soit nécessaire d'ajouter cette fonctionnalité à gitea core. c'est peut-être ok pour un plugin quand l'architecture du plugin gitea est prête.

@renothing Si je comprends bien le problème abordé ici, cela va bien au-delà de la fusion d'un simple résumé. Il s'attaque à la fusion entre plusieurs instances gitea différentes, et même entre un référentiel GitHub et un sur une instance gitea. Il permet de fusionner les modifications de n'importe quelle branche distante sur n'importe quel serveur git pris en charge sur Internet.

@stevenroose Corrigez-moi si je me trompe :smiley:

@sbrl
vous avez raison, mais si quelqu'un veut contribuer à votre dépôt, il devra d'abord récupérer votre code, il doit garder deux télécommandes (une pour lui, une pour la vôtre). cela n'a pas du tout réduit les travaux. cette fonctionnalité ne fait que réduire l'étape de connexion/enregistrement. cela n'a pas beaucoup aidé, peut-être que l'envoi du chemin d'accès au courrier électronique est un meilleur choix, comme le noyau Linux.

je ne suis pas d'accord avec toi @renothing

1. Lorsque vous travaillez avec git, vous avez toujours de nombreuses télécommandes
2. C'est un incontournable
3. l'étape de connexion est ennuyeuse
4. gitlab le fera aussi : https://gitlab.com/gitlab-org/gitlab-ce/issues/4013
5. c'est une fonctionnalité principale donc ce n'est pas un plugin

Je suis tout à fait favorable à la prise en charge des demandes d'extraction fédérées, de toute façon
Je ne pense pas qu'ils pourraient remplacer la connexion, comme vous le souhaitez toujours
accorder/révoquer en quelque sorte les autorisations de déposer des PR et de commenter
le fil correspondant.

La partie connexion doit être prise en charge par OpenID Login (il y a
un autre billet à propos de cette partie).

@renothing Pour autant que je

De plus, si vous ne l'aimez pas, je suis sûr qu'il y aura une option pour le désactiver - personne ne vous dit que vous devez l'utiliser :smiley:

En effet. Vous pouvez utiliser GitHub, j'utilise mon propre Gitea. Si vous souhaitez contribuer à mon projet, je ne souhaite pas que vous ayez un compte sur mon instance Gitea, car vous utilisez GitHub. Je veux que vous poussiez une fonctionnalité dans une branche de votre dépôt sur GitHub, puis reveniez à mon instance, la page d'accueil du projet et déposiez un PR de votre branche GitHub dans la branche principale. Sans que vous ayez besoin de créer un compte, il vous suffit de vous connecter avec votre compte GitHub (peut-être faire un CAPTCHA) et de coller l'URL dans votre branche GitHub.

Comme je l'ai peut-être observé dans un autre PR (celui d'OpenID) même si quelqu'un se connecte
avec un mécanisme d'authentification à distance (OpenID dans mon cas, GitHub/OAuth2
dans l'exemple que vous faites) il a encore besoin d'un enregistrement sur l'instance locale,
sinon pour pouvoir participer à la discussion sur sa proposition
changements, et peut-être être notifié par mail des réponses.

Ainsi, permettre de référencer des branches sur des serveurs git distants doit principalement
faire avec la suppression de la nécessité pour un contributeur d'être autorisé à
et en fait créer un nouveau référentiel git pour le code qu'il héberge déjà
ailleurs. Pour donner fondamentalement la liberté d'héberger des forks sur arbitraire
hébergeurs.

Peut-être qu'un jour nous obtiendrons des autorisations suffisamment précises pour pouvoir
avoir des utilisateurs qui peuvent envoyer des PR mais pas créer des référentiels/forks locaux.

pour garder gitea core simple, je n'aime pas du tout cette fonctionnalité. cela rendra les fonctionnalités de base plus complexes, non seulement le système de demande de tirage, également avec un système d'autorisation et difficile à intégrer avec le 3ème système CI. de toute façon, les auteurs principaux ont le droit de choisir.

@renothing Eh bien, les auteurs principaux ne sont pas ceux qui devraient choisir, ce sont les utilisateurs qui devraient le faire.

Sur CI, je ne pense pas que ce soit un problème. Ce que fait CI, c'est simplement extraire une branche et exécuter des scripts. Étant donné que le système CI est probablement séparé de l'instance Gogs de toute façon, cela ne fait vraiment aucune différence d'extraire une branche du référentiel Gogs ou de tout autre référentiel distant.

En outre, un système d'autorisation devrait être en place de toute façon. Mais cela ne devrait pas être plus compliqué que d'avoir simplement une case à cocher supplémentaire pour les « comptes d'invité ». Vous avez des autorisations telles que _commit, faire des problèmes, faire des relations publiques et commenter_, puis vous auriez trois types d'utilisateurs _membres du dépôt, des comptes enregistrés chez Gogs et des invités_. Ez z

L'idée d'un drapeau unique pour un « compte invité » semble intéressante.
Mais alors, aucun invité ne pourrait « regarder » les changements, n'est-ce pas ?

Vous déposeriez un RP fédéré et n'obtiendriez pas les commentaires, à moins que
votre email (et vos préférences) sont connus du système.

Êtes-vous d'accord pour qu'un enregistrement local doive être créé de toute façon pour l'utilisateur ?

@strk. Vous le feriez. Les invités se connectent avec OpenID, afin que leur adresse e-mail soit connue. La base de données utilisateur doit simplement faire une distinction entre les utilisateurs "réels" et les invités.

Avec "pas membre de cette instance", je ne voulais pas dire qu'il n'y avait aucune trace d'eux dans la base de données.

Vous auriez encore besoin de savoir quel email (et donc utilisateur) notifier lors de la réception de commentaires sur un ticket, il doit donc y avoir une association entre un ticket (PR) et un "utilisateur" (invité ou non) - cela signifie toujours avoir un enregistrement dans la base de données, pour cette association.

BTW, l'e-mail fourni par OpenID n'est pas nécessairement fiable/confirmé, donc si vous voulez être sûr de l'e-mail, vous devez toujours vous en occuper

Document de conception intéressant par des personnes de NotABug avec des idées sur un service d'hébergement git fédéré : https://notabug.org/NotABug.org/notabug/src/master/README.md

OAuth pour GH/BB/GL peut être utilisé pour lier une seule fois un compte, puis si vous l'autorisez, Gitea répertorie vos dépôts et branches distants et vous pouvez créer des PR vers n'importe quel dépôt ayant un ancêtre commun (trouver cela va être si pénible. ..). Le seul problème que je vois est que _all_ l'autre système (GitHub, BitBucket, GitLab) a différentes API pour récupérer ces données, nous aurions besoin de prendre en charge tout ou rien. Je dis plugins :trollface:

@strk Ce document de conception a l'air bien en théorie, mais en pratique, personne ne le supporte (au moins GH/BB/GL ne le fait pas, n'hésitez pas à signaler quelqu'un qui le fait, OU au moins a l'intention _réelle_ de le faire) donc dans en réalité, c'est principalement des anecdotes jusqu'à ce qu'au moins un autre l'ait mis en œuvre.
On pourrait contrer cela avec "mais nous pourrions être les premiers!", si nous sommes les premiers et que tout le monde s'installe sur un autre "standard", nous nous retrouvons bloqués et devons prendre du _temps de passe-temps personnel_ pour remplacer notre flux existant par ledit autre standard , cassant éventuellement le flux de courant. Si nous utilisons plutôt une technique existante qui est en quelque sorte viable et que les autres choisissent quelque chose, nous pourrions l'implémenter à la place. Mais jusqu'à ce moment-là, je m'abstiendrais d'introduire une "fédération" alors qu'elle n'est pas exactement fédérée. Faites-le une fois, et faites-le bien

C'est vraiment un problème de poule et d'œuf. Jusqu'à ce que quelqu'un implémente la fédération, personne n'implémentera la fédération.

EDIT : Je dirais également que si nous pouvons fédérer entre les instances de gogs, nous avons déjà fait un premier pas vers la fédération.

@roblabla D'accord , je ne suis pas contre les demandes d'extraction entre les instances, ce que je dis c'est _utiliser les fonctionnalités existantes_, telles que les différentes API de fournisseurs :)

Je préférerais une solution générique à une solution liée à une API connue, en particulier à partir de services propriétaires.

Je suis d'accord avec @strk. Git lui-même est assez puissant, j'essaierais de recourir autant que possible aux fonctionnalités de base de Git.

Si la fédération est implémentée sur la base des URI Git, l'ajout de sucre d'interface utilisateur pour les fournisseurs d'hébergement n'est pas si difficile. Pour Gitea, nous utilisons nos propres API pour extraire les informations du PR. Pour GH/GL/... nous ne pouvons pas les prendre en charge, donc il suffit de prendre en charge les URI Git copier-coller, ou d'implémenter un widget d'interface utilisateur pour récupérer ces URI à partir des API. Ou encore plus simple, mappez les URL PR aux URI Git.

Un problème est qu'il n'y a pas de moyen standard de représenter une branche dans un référentiel distant, pour autant que je sache. Je pense que j'ai déjà vu git://provider/repo.git#refs/mybranchref , mais je ne sais pas à quel point c'est standard.

Le mercredi 22 mars 2017 à 09:47:06 -0700, Steven Roose a écrit :

Un problème est qu'il n'y a pas de moyen standard de représenter une branche dans un référentiel distant, pour autant que je sache. Je pense que j'ai déjà vu git://provider/repo.git#refs/mybranchref , mais je ne sais pas à quel point c'est standard.

Je ne vois pas en quoi c'est un problème.
Dites simplement que pour soumettre une "pull request fédérée", vous aurez
de fournir toutes les informations que "git request-pull" vous demande de
apporter ...

Il ne s'agit pas nécessairement d'une seule URL, cela peut aussi être un formulaire complet...

Que diriez-vous de demander à GH/GL leur retour d'expérience sur une proposition de norme ? Peut être une ouverture sur une discussion plus large sur le sujet

Bien sûr, mais nous avons d'abord besoin de cette norme proposée ...

Le système Pagure (https://pagure.io/pagure) prend en charge la demande d'extraction à distance, ce que j'ai trouvé utile en travaillant sur le référentiel de packages Fedora. Vous devez être enregistré pour faire une demande d'extraction à distance.

Voir : https://docs.pagure.org/pagure/usage/pull_requests.html#remote -git-to-pagure-pull-request

Connexe : https://github.com/gogits/gogs/issues/4437

des nouvelles à ce sujet? Il y a actuellement beaucoup de reportages sur l'acquisition de Github par Microsoft, donc la fédération dans le contexte d'un service Web git serait super cool :)

Je viens littéralement de chercher ce problème une minute avant de voir la notification de votre commentaire. Ceci (et les demandes de tirage fédérées) est vraiment la fonctionnalité qui tue pour la prochaine plate-forme Git. Je vois un onglet de connexion OpenID, mais il n'est pas très convivial en ce qui concerne l'accès facile aux grands fournisseurs OpenID comme Google. Je n'ai vu qu'une exception faite pour GitHub.

Salut à tous. J'ai trouvé ce problème en regardant autour de ce qui se faisait au sujet des infrastructures git fédérées, suite au rachat de GitHub par Microsoft.

Quand il s'agit de fédérer les identités d'utilisateurs, les commentaires, l'activité… et je suppose que les requêtes pull / merge également, je pense que le faire en utilisant la norme ActivityPub ferait encore plus que simplement fédérer les infrastructures git ensemble : cela fédérerait les infrastructures git avec d'autres ActivityPub implémentations. Par exemple, cela peut vous permettre de commenter une pull request sur une instance Gitea à partir d'une instance Mastodon , de suivre un rapport de bogue dans une vidéo sur une instance PeerTube ou un diaporama sur une instance MediaGoblin avec un ticket sur une instance GitLab …

Mes 2 cts ;)

Faire écho à ce que @Arkanosis a écrit : il semble que ce soit l' objectif de

Une spécification comme celle-ci doit être acceptée par au moins certaines des implémentations de services Web Git. Si vous êtes un développeur d'un tel logiciel, veuillez vous joindre à notre discussion et vous exprimer. Nous vous ajouterons simplement au groupe de travail.

Je ne sais pas si le commentaire de @Arkanosis s'appliquerait également à la diaspora, mais ce serait certainement utile pour moi si c'était le cas ! J'attends cette fonctionnalité avec impatience ! :)

Je ne sais pas si le commentaire @Arkanosis s'appliquerait également à la diaspora

@KingDuckZ : Je souhaite ! La dernière fois que j'ai vérifié, Diaspora n'implémentait pas ActivityPub, cependant. J'aimerais beaucoup qu'il le fasse pour se fédérer avec d'autres réseaux (notamment avec Mastodon). Cela faciliterait, en plus, la fédération de la diaspora et de tout ce qui ressort de cette proposition (GitPub ou autre).

Bien sûr, il serait possible de se fédérer directement avec Diaspora en utilisant le protocole de fédération de diaspora (webfingers + microformats + autres), mais ce protocole ne semble pas avoir autant de traction qu'ActivityStreams / ActivityPub.

Merci de rester dans le sujet. Ce problème est uniquement lié à la possibilité d'ouvrir des demandes d'extraction à partir de dépôts distants. Tout ce qui est nécessaire pour y parvenir est une formulation commune de "repo and branch".

Un exemple serait https://github.com/go-gitea/gitea.git#federated-prs .

La fédération d'autres données comme les problèmes et les commentaires est hors de portée pour cela. Je pense que dans un premier temps, vous devriez pouvoir faire un PR sans créer de compte sur un dépôt git.

@stevenroose si vous vous référez à moi : excuses, j'aurais dû mieux le placer dans #1612 en effet. Pendant ce temps, quelqu'un d'autre l'a mentionné là-bas.

Il existe maintenant un groupe de travail/projet pour la conception d'un protocole de fédération git basé sur ActivityPub. https://github.com/git-federation/gitpub

Rejoignez leur liste de diffusion si vous êtes intéressé.

GitLab l'implémente !
https://gitlab.com/gitlab-org/gitlab-ce/issues/40830
https://gitlab.com/groups/gitlab-org/-/epics/260

Niiiii !

Git fédéré serait génial. Je n'aime pas enregistrer d'innombrables comptes pour les dépôts git...
PR et problèmes fédérés ! ??

@pwFoo, je pense qu'il faudra un certain temps pour spécifier et implémenter cela.

Je n'aime pas enregistrer d'innombrables comptes pour les dépôts git...

Serait-ce une option pour vous de "Se connecter avec GitHub" alors qu'il suffit d'un clic jusque-là ?

Cela pourrait être une solution de contournement, mais l'objectif devrait fédérer les problèmes / RP, les réseaux sociaux fédérés (mastodon, pleroma, misskey, ...) à l'avenir.

Cela pourrait être une solution de contournement, mais l'objectif devrait fédérer les problèmes / RP, les réseaux sociaux fédérés (mastodon, pleroma, misskey, ...) à l'avenir.

Quel est le cas d'utilisation de cela? Écraser gitea pour partager avec force des informations entre les plates-formes ActivityPub et GitFed ou toute autre solution construite ici conduirait à une sur-ingénierie.

@jalcine Le cas d'utilisation est que si vous travaillez sur plusieurs projets logiciels différents, vous n'êtes pas obligé de créer et de maintenir un compte sur toutes les plateformes sur lesquelles ces projets sont hébergés (GitHub, GitLab ou leur propre Gitea/GitLab/ peu importe). Idéalement, vous avez votre propre référentiel (GitHub, GitLab ou votre propre Gitea personnalisé) et vous pouvez créer des PR pour tous les projets sur lesquels vous travaillez à partir de votre propre référentiel.

D'accord, mais la personne à qui je répondais disait que vous vous connecteriez en utilisant Mastodon à Gitea ?

Dans mon cas, j'ai une instance Gitea sur un serveur domestique. Mon raspberry pi et ma connexion internet ont des ressources limitées. Et je veux empêcher que les bots puissent créer des comptes afin que j'aie moins d'administration pendant mon temps libre.

Pour cette raison, j'ai désactivé la page d'inscription. Ainsi, personne n'est en mesure d'ajouter des problèmes à mes dépôts publics.

Actuellement, le seul moyen d'obtenir des problèmes des personnes est d'utiliser un référentiel miroir sur Github. Mais ensuite, je peux fermer mon instance Gitea.

Le seul moyen pour lequel Gitea sera meilleur que Github est qu'il prend en charge les problèmes fédérés et les pull request (principe de décentralisation).

Les réseaux sociaux comme mastodonte sont un autre sujet et agréable à avoir.

Mais les problèmes fédérés et les demandes d'extraction sont indispensables pour que les utilisateurs n'aient pas à se soucier de la création de compte à chaque instance, comme Nextcloud/Owncloud.

@jalcine
"Git fédéré serait génial. Je n'aime pas enregistrer d'innombrables comptes pour les dépôts git...
PR et problèmes fédérés ! "

Le but n'est pas de se connecter avec GitHub ou un compte Mastodon... J'ai cité ma réponse.
L'objectif est d'utiliser un seul compte (idéalement le mien) pour ouvrir des problèmes, répondre ou ouvrir des PR.

J'ai verrouillé ce problème car il est actuellement discuté dans la liste de diffusion forgée, veuillez y rediriger toutes les conversations.

Plus d'infos : https://github.com/forgefed/forgefed