Gitea: Suporte a solicitações de pull federado

_De @roblabla em 25 de maio de 2016 12: 9_

Algo relacionado: https://github.com/gogits/gogs/issues/2210

Este é o recurso número um para um serviço Git hospedado pessoal!
Seria ainda maior com o # 185!

Isso poderia ser integrado com a integração git-appraise também?

Propostas formais

O GitLab está rastreando esse problema aqui , então talvez você possa redigir um fluxo de trabalho simplificado. Eles estão planejando mencionar o recurso durante o encontro.

@bkcsoft talvez você possa ajudar a manter as especificações do GitLab abertas o suficiente para permitir a federação de PR entre o GitLab e o Gitea também?

@strk é @bkcsoft afiliado ao GitLab?

@strk Eu poderia direcioná-lo na direção de apenas enviar arquivos de patch entre servidores (talvez usando webhooks?). Que é o que eu sugiro que Gitea deve fazer também. Torna _realmente_ fácil não ter que empurrar / puxar entre servidores :)
@stevenroose Sim

Bem, parece que eles já estão pensando ou usando git request-pull -p (que envia o patch junto), então deve ser compatível com várias plataformas: ligeiramente_smiling_face:

Eles estão planejando mencionar o recurso durante o encontro.

https://gitlab.com/gitlab-org/gitlab-ce/issues/4013 está marcado como moonshot , não atribuído, sem marco e sem MR à vista. Portanto, talvez não tenha muitas esperanças ainda: ligeiramente_smiling_face:

@bkcsoft Podemos assumir a liderança aqui :) Se conseguirmos colocar o GitLab e o GitHub a bordo, isso encerraria o bloqueio atualmente imposto por essas plataformas

@bkcsoft Podemos assumir a liderança aqui :) Se conseguirmos colocar o GitLab e o GitHub a bordo, isso encerraria o bloqueio atualmente imposto por essas plataformas

Não consigo acreditar que o GitHub queira resolver o problema de bloqueio: P

Não, mas se outras plataformas abrirem o caminho, as pessoas podem exigir que o sigam. E as pessoas podem migrar :)

Softwares como o Gerrit permitem que

@stevenroose , você tem referência sobre o suporte Gerrit?

Se implementarmos Gerrit, poderíamos convidar a equipe Golang para usar Gitea? 😄

@strk Com o Gerrit, você empacota seus commits usando git-review e os envia para uma determinada referência e isso aparecerá no Gerrit como uma revisão de código. Não há necessidade de criar um garfo Gerrit. No entanto, ele não usa git request-pull .

Você ainda precisa de permissões de gravação para o repo para enviá-los
comentários para o árbitro, certo?

Nesse caso, o bit ausente ainda estaria eventualmente rastreando
um repo diferente contendo a referência de revisão?

Sim, é diferente. Ele envia bits individuais com permissão de gravação.

Com PRs federados, Gitea deve periodicamente (ou a pedido) verificar a referência do ramo para novas alterações.

AFAIK, git request-pull não usa git commits. Ele simplesmente gera uma lista de commits entre local e remoto, e a imprime em stdout. Precisamos especificar uma forma de enviar essas alterações para controles remotos / retirá-los dos controles remotos

Git request-pull faz parte da instalação padrão do git, ao contrário do git appraise ou git review.

@roblabla Sim, o fluxo seria salvar git request-pull em um arquivo e carregá-lo (como o envio de patches costumava funcionar no passado). Ou insira um URL para um branch de um repo remoto para que o Gitea possa atualizar o PR.

A menos que eu esteja perdendo algo git request-pull referência a um commit específico,
enquanto as solicitações de pull do github / gitea fazem referência a um branch (possivelmente em movimento).

Queremos que a solicitação federada rastreie branches ao invés de commits específicos?
Acho que queremos um PR (tópico de comentários / discussão) para rastrear uma filial.

ele faz referência a _comprometimentos_ específicos. Portanto, precisaríamos buscar novamente os dados continuamente 😒

Na terça-feira, 20 de dezembro de 2016 às 12:20:34 AM -0800, bkcsoft escreveu:

ele faz referência a _comprometimentos_ específicos. Portanto, precisaríamos buscar novamente os dados continuamente 😒

Só podemos buscar novos commits se tivermos uma referência a um nome de branch,
que não está na saída de git request-pull . Então, se quisermos manter o
track-a-branch abordagem, não podemos confiar em git request-pull .

Um criador de relações públicas pode pedir um URL remoto e um nome de filial, verifique o
filial remota localmente, execute algumas verificações (ou seja: recuse-se a criar PR com
um grande número de mudanças) e criar o PR.

Em seguida, um botão e um webhook podem ser disponibilizados para buscar mais
confirma, se houver, do ramo remoto. Apenas o autor de relações públicas deve ser
dada a capacidade de solicitar atualizações. Colocando um gancho git em seu garfo
acertar o webhook de destino tornaria a experiência de atualização mais suave.

--strk;

Eu sugeriria que, ao criar um PR como uma conta de convidado, você teria uma guia com "externo" ou "federado" ou o que quer que tenha duas opções:

1. um campo de entrada de texto para um URL de filial, com um botão "buscar" ou "testar", talvez para verificar a acessibilidade e disponibilidade de rastreamento

2. um campo de upload de arquivo para enviar um arquivo .diff , .patch ou a saída de um git-request-pull ; isso também pode ser uma área de texto

No último caso, uma vez que o PR é criado, os usuários devem ser capazes de sobrescrever seu arquivo anterior para alterar os commits no PR.

Além disso, no caso de indisponibilidade de atualizações automáticas de ramificação, você pode exigir que um usuário acione manualmente uma nova busca. Em quase todos os casos, os usuários se comprometem com um branch baseado em PR exclusivamente à luz do commit, então eles podem apenas buscar novamente sempre que atualizar o branch. (Leve em consideração que, frequentemente, as atualizações de um commit são por causa do feedback no PR, então eles têm a página aberta de qualquer maneira.)

Como disse o promotor de minha tese: "A verdadeira oposição a uma mudança não vem das pessoas que são contra, mas de pessoas que insistem em dizer que não é suficiente."

Não acho esse recurso útil, você pode adicionar dois remotos para este caso. por exemplo branch github para gh, master para gogs, eu uso ambos no meu trabalho com um repositório. e git review é outra coisa. não faça um grande recurso para resolver pequenos problemas.
de qualquer forma, os gogs se concentram em pequenas empresas ou auto-hospedagem. não para serviço de nuvem pública.

@renothing Acho que você não entendeu totalmente a proposta. Não tem nada a ver com ser capaz de comparar ou verificar o código de diferentes fontes remotas. Em vez disso, trata-se de permitir que as pessoas enviem solicitações pull ou patches sem ter que se registrar em seu sistema. Se eu publicar um software em minha instância do Gitea, quero que outros possam criar um PR sem exigir que eles tenham o trabalho de registrar, bifurcar, enviar suas alterações para minha instância e, em seguida, criar um PR.

@stevenroose
como eu disse, é uma pequena cena de demanda. pense nisso, quantas pessoas precisam fundir um PR da essência? Não acho que seja necessário adicionar esse recurso ao gitea core. talvez esteja tudo bem para um plugin quando a arquitetura do plugin gitea estiver pronta.

@renothing Se eu entendi o problema que está sendo abordado aqui corretamente, vai muito além de mesclar apenas uma essência simples. Ele lida com a fusão entre várias instâncias diferentes do gitea e até mesmo entre um repositório do GitHub e um em uma instância do gitea. Ele permite mesclar alterações de qualquer branch remoto em qualquer servidor git compatível na Internet.

@stevenroose Corrija-me se eu estiver errado: smiley:

@sbrl
você está certo, mas se alguém quiser contribuir para o seu repo, ele vai precisar buscar o seu código primeiro, ele deve ter que manter dois remotos (um para ele, um para o seu). não reduziu os trabalhos de forma alguma. este recurso apenas reduz a etapa de login / registro. não ajudou muito, talvez o caminho de envio de e-mail seja uma escolha melhor, como o kernel do Linux.

eu não estou bem com você @renothing

1. Quando você trabalha com o git, você sempre tem muitos controles remotos
2. É necessário ter
3. etapa de login é chata pra caralho
4. O gitlab também fará isso: https://gitlab.com/gitlab-org/gitlab-ce/issues/4013
5. é um recurso principal, então não é um plugin

Sou totalmente a favor de ter suporte para solicitações de pull federadas, de qualquer maneira
Eu não acho que eles poderiam substituir o login, como você ainda quer
de alguma forma conceder / revogar permissões para arquivar PRs e comentar sobre
o segmento correspondente.

A parte de login deve ser tratada pelo login OpenID (há
outro ingresso sobre essa parte).

@renothing Até onde eu posso dizer, na verdade, será o servidor que busca automaticamente o código do remoto automaticamente, o que significa que o cara que está fazendo a solicitação de pull só tem que empurrar para um branch em seu próprio servidor, e não não precisa ter 2 controles remotos (novamente, corrija-me se eu estiver errado).

Além disso, se você não gostar, tenho certeza de que haverá uma opção para desativá-lo - ninguém está dizendo que você deve usá-lo: smiley:

De fato. Você pode usar o GitHub, eu uso meu próprio Gitea. Se você quiser contribuir com meu projeto, não quero que você tenha uma conta na minha instância do Gitea, porque você usa o GitHub. Quero que você coloque um recurso em um branch em seu repo no GitHub, depois volte para minha instância, a página inicial do projeto e arquive um PR do seu branch GitHub para o master. Sem a necessidade de criar uma conta, tudo o que você faz é fazer o login com sua conta GitHub (talvez fazer um CAPTCHA) e colar a URL em seu branch GitHub.

Como talvez eu tenha observado em outro PR (o OpenID), mesmo que alguém logue
com um mecanismo de autenticação remota (OpenID no meu caso, GitHub / OAuth2
no exemplo que você faz) ele ainda precisa de um registro na instância local,
senão poder participar da discussão sobre sua proposta
mudanças e talvez seja notificado por e-mail com as respostas.

Portanto, permitir a referência de branches em servidores remotos git deve principalmente
fazer com a remoção da necessidade de um contribuidor receber permissão para
e criar um novo repositório git para o código que ele já hospeda
Em outro lugar. Para dar basicamente a liberdade de hospedar garfos em
hosters.

Talvez um dia obtenhamos permissões refinadas o suficiente para sermos capazes
ter usuários que podem enviar PRs, mas não podem criar repositórios / bifurcações locais.

para manter o gitea core simples, não gosto desse recurso. isso tornará os principais recursos mais complexos, não apenas o sistema de solicitação de pull, também com sistema de permissão e difícil de integração com o terceiro sistema de CI. de qualquer forma, os autores principais têm o direito de escolha.

@renothing Bem, os autores principais não são os que devem escolher, são os usuários que devem.

Na CI, não acho que isso seja um problema. O que o CI faz é apenas puxar um branch e executar alguns scripts. Como o sistema CI é provavelmente separado da instância Gogs de qualquer maneira, realmente não faz diferença puxar um branch do repositório Gogs ou de qualquer outro repo remoto.

Além disso, um sistema de permissão deve estar em vigor de qualquer maneira. Mas não deve ser mais complicado do que apenas ter uma caixa de seleção extra para "Contas de convidados". Você tem permissões como _comprimir, fazer problemas, fazer PRs e comentar_ e então você teria três tipos de usuários _membros do repo, contas registradas no Gogs e Convidados_. Ez πz

A ideia de uma única bandeira para uma "conta de convidado" parece interessante.
Mas então nenhum convidado poderia estar "assistindo" às mudanças, certo?

Você estaria preenchendo um PR federado e não obteria comentários sobre ele, a menos que
seu e-mail (e preferências) são conhecidos pelo sistema.

Você concorda que um registro local deve ser criado de qualquer maneira para o usuário?

@strk. Você poderia. Os convidados fazem login com OpenID, para que seus endereços de e-mail sejam conhecidos. O banco de dados do usuário deve apenas fazer uma distinção entre usuários "reais" e usuários convidados.

Com "não membro desta instância", não quis dizer que não havia nenhum registro deles no banco de dados.

Você ainda precisa saber qual e-mail (e, portanto, usuário) notificar ao receber comentários sobre um tíquete, então deve haver uma associação entre um tíquete (PR) e um "usuário" (convidado ou não) - isso significa ainda ter um registro em banco de dados, para essa associação.

BTW, o e-mail fornecido pelo OpenID não é necessariamente confiável / confirmado, então se você quiser ter certeza sobre o e-mail, ainda precisa cuidar disso

Documento de design interessante por pessoas do NotABug com ideias sobre um serviço de hospedagem git federado: https://notabug.org/NotABug.org/notabug/src/master/README.md

OAuth para GH / BB / GL pode ser usado para vincular uma conta, então, se você permitir, o Gitea lista seus repositórios e branches remotos e você pode criar PRs para qualquer repo que tenha um ancestral comum (descobrir isso será uma dor de cabeça. ..). O único problema que vejo é que _todos_ o outro sistema (GitHub, BitBucket, GitLab) tem APIs diferentes para buscar esses dados, precisamos oferecer suporte a todos ou a nenhum. Eu digo plugins: trollface:

@strk Esse documento de design parece bom em teoria, mas na prática ninguém o suporta (pelo menos GH / BB / GL não, sinta-se à vontade para apontar alguém que sim, OU pelo menos tem _actuall_ intenção de fazê-lo) então em a realidade é principalmente trivialidades até que pelo menos um outro o tenha implementado.
Alguém pode se opor a isso com "mas poderíamos ser os primeiros!", Se formos os primeiros e todos os outros decidirem por outro "padrão", ficamos perdidos e temos que tomar _tempo de passatempo pessoal_ para substituir nosso fluxo existente pelo outro padrão , possivelmente interrompendo o fluxo atual. Se, em vez disso, usarmos alguma técnica existente que seja viável e as outras decidirem por algo, poderemos implementá-la. Mas até o momento eu me absteria de introduzir "federação" quando não é exatamente federada. Faça uma vez, e faça certo 🙂

Este é realmente um problema do ovo e da galinha. Até que alguém implemente a federação, ninguém a implementará.

EDIT: Eu também diria que, se pudermos federar as instâncias do gogs, já demos o primeiro passo em direção à federação.

@roblabla Certo, não sou contra solicitações de pull entre instâncias, o que estou dizendo é _use a funcionalidade existente_, como as APIs de vários provedores :)

Eu prefiro uma solução genérica a uma que seja vinculada a uma API conhecida, especialmente de serviços proprietários.

Eu concordo com @strk. O Git em si é bastante poderoso, eu tentaria recorrer o máximo possível à funcionalidade central do Git.

Se a federação for implementada com base em URIs do Git, adicionar UI sugar para provedores de hospedagem não é tão difícil. Para Gitea, usamos nossas próprias APIs para extrair informações do PR. Para GH / GL / ..., não podemos suportá-los, então apenas suporte copiar e colar URIs do Git ou implementar um widget de IU para recuperar esses URIs das APIs. Ou ainda mais simples, mapeie URL de PR para URI de Git.

Um problema é que não existe uma maneira padrão de representar uma ramificação em um repo remoto, até onde eu sei. Acho que já vi git://provider/repo.git#refs/mybranchref antes, mas não tenho certeza de como isso é padrão.

Na quarta-feira, 22 de março de 2017 às 09:47:06 -0700, Steven Roose escreveu:

Um problema é que não existe uma maneira padrão de representar uma ramificação em um repo remoto, até onde eu sei. Acho que já vi git://provider/repo.git#refs/mybranchref antes, mas não tenho certeza de como isso é padrão.

Não vejo como isso seja um problema.
Basta dizer que, para enviar uma "solicitação de pull federado", você terá
para fornecer todas as informações que "git request-pull" pede que você
fornecer ...

Não é necessariamente um único URL, pode ser um formulário inteiro também ...

Que tal pedir feedback ao GH / GL sobre um padrão proposto? Pode ser uma abertura para uma discussão mais ampla sobre o assunto

Claro, mas primeiro precisamos daquele padrão proposto ...

O sistema Pagure (https://pagure.io/pagure) suporta solicitação remota de pull, que achei útil ao trabalhar no repositório de pacotes do Fedora. Você precisa estar registrado para fazer uma solicitação de pull remoto.

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

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

Alguma novidade sobre isso? Atualmente, há muita cobertura de notícias sobre o Github sendo adquirido pela Microsoft, então federação no contexto de um serviço da web git seria muito legal :)

Literalmente, vim pesquisar este problema um minuto antes de ver a notificação do seu comentário. Este (e as solicitações de pull federadas) é realmente o recurso matador para a próxima plataforma Git. Vejo uma guia de login do OpenID, mas não é muito amigável com relação ao acesso fácil aos grandes provedores de OpenID como o Google. Eu vi apenas uma exceção feita para o GitHub.

Olá a todos. Eu encontrei esse problema enquanto examinava o que estava sendo feito sobre o assunto de infraestruturas git federadas, após a compra do GitHub pela Microsoft.

Quando se trata de federar identidades de usuário, comentários, atividades ... e eu acho que solicitações de pull / merge também, acho que fazer isso usando o padrão ActivityPub faria ainda mais do que apenas federar infraestruturas git: federaria infraestruturas git com outro ActivityPub implementações. Por exemplo, pode permitir que você comente a solicitação pull em uma instância Gitea de uma instância Mastodon , para acompanhar um relatório de bug em um vídeo em uma instância PeerTube ou um conjunto de slides em uma instância MediaGoblin com um tíquete em uma instância GitLab …

Meus 2 cts;)

Afirmando o que GitPub visa. Talvez algum Gitea devs tenha tocado lá? Isso é o que é pedido atualmente:

Uma especificação como essa deve ser acordada por pelo menos algumas das implementações de serviço da web do Git. Se você é um desenvolvedor de tal software, por favor, junte-se à nossa discussão e manifeste-se. Vamos simplesmente adicionar você ao grupo de trabalho.

Não tenho certeza se o comentário de @Arkanosis também se aplicaria ao Diaspora, mas definitivamente seria útil para mim se fosse o caso! Ansioso por este recurso! :)

Não tenho certeza se o comentário de @Arkanosis também se aplica ao Diaspora

@KingDuckZ : Eu desejo! A última vez que verifiquei, Diaspora não estava implementando ActivityPub, no entanto. Eu realmente gostaria de fazer isso para federar com outras redes (especialmente com Mastodon). Isso, como um benefício adicional, tornaria muito mais fácil federar o Diaspora e o que quer que saia dessa proposta (GitPub ou qualquer outro).

Claro, seria possível federar diretamente com o Diaspora usando o protocolo de federação da diaspora (webfingers + microformatos + outros), mas este protocolo não parece obter tanta tração quanto ActivityStreams / ActivityPub.

Por favor, fique no tópico. Esse problema está relacionado apenas à capacidade de abrir solicitações de pull de repositórios remotos. Tudo o que é necessário para alcançar isso é uma formulação comum de "repo e ramificação".

Um exemplo seria https://github.com/go-gitea/gitea.git#federated-prs .

A federação de outros dados, como problemas e comentários, está fora do escopo para isso. Acho que, como primeira etapa, você deve ser capaz de fazer um PR sem criar uma conta em um repositório git.

@stevenroose se você se refere a mim: desculpas, eu deveria ter colocado melhor em # 1612, de fato. Enquanto isso, outra pessoa mencionou isso lá.

Agora existe um grupo de trabalho / projeto para criar um protocolo de federação git baseado em ActivityPub. https://github.com/git-federation/gitpub

Junte-se à lista de discussão deles se estiver interessado.

O GitLab está implementando isso!
https://gitlab.com/gitlab-org/gitlab-ce/issues/40830
https://gitlab.com/groups/gitlab-org/-/epics/260

Niiiice!

O git federado seria incrível. Não gosto de registrar contas incontáveis ​​para repositórios git ...
PRs federados e questões! 👍

@pwFoo acho que vai demorar algum tempo para especificar e implementar isso.

Não gosto de registrar contas incontáveis ​​para repositórios git ...

Seria uma opção para você "Entrar com GitHub" quando falta apenas um clique até então?

Pode ser uma solução alternativa, mas o objetivo deve ser problemas / PRs federados, redes sociais federadas (mastodonte, pleroma, misskey, ...) no futuro.

Pode ser uma solução alternativa, mas o objetivo deve ser problemas / PRs federados, redes sociais federadas (mastodonte, pleroma, misskey, ...) no futuro.

Qual é o caso de uso disso? Esmagar o gitea para forçar o compartilhamento de informações entre as plataformas ActivityPub e o GitFed ou qualquer solução construída aqui levaria a uma superengenharia.

@jalcine O caso de uso é que se você trabalha em vários projetos de software diferentes, não é necessário criar e manter uma conta em todas as plataformas em que esses projetos estão hospedados (GitHub, GitLab ou seu próprio Gitea / GitLab / auto-hospedado qualquer que seja). Idealmente, você tem seu próprio repo (GitHub, GitLab ou seu próprio Gitea personalizado) e pode fazer PRs para todos os projetos em que trabalha a partir de seu próprio repo.

Certo, mas o que a pessoa para quem eu estava respondendo estava dizendo que você faria login usando Mastodon para Gitea?

No meu caso, tenho uma instância Gitea em um servidor doméstico. Meu pi raspberry e minha conexão com a internet têm recursos limitados. E quero evitar que bots possam criar contas para que eu tenha menos administração no meu tempo livre.

Por causa disso, desativei a página de registro. Assim, ninguém é capaz de adicionar problemas aos meus repositórios públicos.

Atualmente, a única maneira de obter problemas das pessoas é usando um repositório espelho no Github. Mas então, posso fechar minha instância Gitea.

A única maneira em que o Gitea será melhor do que o Github é que ele oferece suporte a problemas federados e solicitações de pull (princípio da descentralização).

Redes sociais como mastodonte são outro tópico e é bom ter.

Mas questões federadas e solicitações pull são essenciais para que as pessoas não precisem se preocupar com a criação de contas em cada instância, como Nextcloud / Owncloud.

@jalcine
"Git federado seria incrível. Não gosto de registrar contas incontáveis ​​para repositórios git ...
PRs federados e questões! 👍 "

O objetivo não é fazer o login com GitHub ou conta Mastodon ... Citei minha resposta.
O objetivo é usar uma conta (de preferência a minha) para abrir questões, responder ou abrir PRs.

Eu bloqueei esse problema, pois ele está sendo discutido na lista de e-mails forjada, redirecione todas as conversas para lá.

Mais informações: https://github.com/forgefed/forgefed