Gitea: Discussão do roteiro Gitea

Uma solução de plugin (incluindo tema) para estender o gitea.

Seria possível adicionar pacotes de SO adequados ao processo de construção? Tenho tentado montar algo para o fedora, mas go parece uma bagunça para empacotar. # 31 meio que fala sobre isso, mas ainda parece estar em aberto.

Estamos usando ansible para implantar o tarball no sistema Debian, isso não é muito prático, mas funciona. Repositórios para as distros mais comuns seriam bons, mas precisam ser implementados e mantidos.

Algumas sugestões:

• Opção para integrar automaticamente Drone CI / CD no Gitea durante o processo de construção.
• Mais capacidade de configuração da administração do site a partir da IU do Gitea, pós-instalação. Por exemplo, gostaria de poder alterar as coisas em _Configuração de serviço_ na página _Configuração_.
• Opção para ocultar o usuário da página Explorar.

Solicitações / problemas / bifurcações de pull federados

Solicitações / problemas / bifurcações de pull federados

Talvez não federado no sentido da palavra Fediverse (ActivityPub, OStatus, diáspora *, etc.), mas eu gostaria da capacidade de interagir com instâncias remotas de sua própria implementação da maneira que melhor se adeque ao projeto.

Também pode ser legal ter equipes e organizações formadas por usuários de várias instâncias, embora isso provavelmente seja incrivelmente difícil de implementar.

Duas sugestões do POV de um usuário final com habilidades mínimas de codificação que tenta ajudar os projetos de código aberto que eu uso relatando bugs e fornecendo feedback de UX:
1) Ajude a padronizar o ForgeFed! Eu adoraria que a UX de arquivar bugs na instância do Gitea (e outras forjas de código hospedadas pela comunidade) fosse como um enorme GH descentralizado.
2) Faça de cada parte de um projeto um repositório Git, de forma que os problemas, wiki etc, possam ser facilmente extraídos, ramificados, empurrados para ou bifurcados. GL e sr.ht fazem isso com pelo menos alguns de seus componentes. Além de ser útil, isso ajudaria potencialmente com o ponto 1)

A capacidade de responder a tíquetes por e-mail seria um grande passo em frente em termos de usabilidade

Permitir a edição de todas as configurações da IU (e talvez alterar o formato do arquivo de configuração durante o processo)

Talvez armazene a maior parte da configuração no banco de dados e forneça CLI e API adequados para ele

@sapk @tboerger Eu diria que deveríamos mudar para o viper para config, dessa forma poderíamos nos livrar do ini (e alguns dos bugs que tivemos com ele) e obter coisas como recarregar a configuração enquanto o Gitea está rodando e as variáveis ​​env adequadas .

Eu estaria disposto a resolver isso, mas não tenho certeza se vou encontrar tempo em um futuro próximo.

Eu também sou a favor do Viper. Eu estava tentando fazer há 2 anos, mas não tive tempo de terminar ... mas posso tentar de novo :)

Pretendo obter um arquivo de configuração mínimo ... Muitas dessas configurações não precisam ser definidas por meio de um arquivo de configuração estático e podem ser facilmente adicionadas ao banco de dados e armazenadas em cache por motivos de desempenho.

Acho que poderíamos primeiro adicionar uma tabela de configuração do banco de dados e mover a maioria dos itens de configuração alteráveis ​​do arquivo ini e deixar apenas os itens que precisam ser recarregados.

@lunny e todos: concordar em mover várias configurações para o banco de dados e permitir que elas sejam configuradas na interface da Web (em todo o site ou em todo o repositório) parece um bom passo em frente. Também seria fácil ter uma ferramenta como o chá ou o próprio gitea capaz de alterar esses valores na linha de comando, para que você ainda pudesse fazer um script de configuração padrão.

O sistema de módulos parece ótimo. Acredito que haja muitas pessoas por aí dispostas a adicionar novas funcionalidades ao gitea.

@belliash @sapk Os plug-ins / módulos IMO não podem ser implementados de forma eficiente sem refatorar o pacote de modelos completamente e adicionar mais abstração. Eu testei várias tecnologias, como o suporte de plug-in nativo do Go.

O resultado foram binários gigantes que dependem fortemente do binário Gitea.

Acho que melhorar o suporte a webhooks e adicionar páginas personalizadas por webhooks é mais realista para ser implementado, uma vez que já temos uma API tranquila e madura que pode ser usada para operações de banco de dados.

@jonasfranz Eu seria

go list -f  '{{ .Imports }}' code.gitea.io/gitea/models 

revela 98 (!) importações diretas. 50 dos quais são centrais não-go.

go list -f  '{{ .Deps }}' code.gitea.io/gitea/models

revela 437 (!!) dependências transitivas. (304 dos quais são núcleo não go)

Veja a fonte do drone, lá nós temos um monte de coisas plugáveis ​​baseadas em webhooks.

Além de fazer sentido um modelo de plugin como o packer, um sistema de plugin baseado em grpc.

@tboerger Você pode fornecer um exemplo do material plugável do drone? Você quer dizer o sistema de plugins baseado em imagens do docker?

Estou falando sobre as extensões para configurações, segredos e assim por diante, as interfaces devem ser definidas em https://github.com/drone/drone/tree/master/plugin

Eu concordo com você, o próximo grande passo do Gitea deve ser o sistema de plugins. Também estou pensando nisso hoje em dia. Vou dar uma chance ao sistema de plugins.

Eu acho que deveria ser semelhante ao sistema de plugins do drone, mas tem mais. Precisamos permitir que um plugin tenha uma IU e deve fazer o login com o OAuth2 da Gitea automaticamente. E devemos ter alguma política de segurança nos plug-ins. e etc.

Quero compartilhar uma tabela comparativa que fizemos por volta de 2016 para _decidir_ qual plataforma de hospedagem escolher para a Open Source Geospatial Foundation. Nessa tabela, listamos recursos que eram importantes para nós. Gitea está em uma das colunas:

https://wiki.osgeo.org/wiki/GitInfrastructureComparison

Você verá que um recurso importante que faltava em 2016 ainda está faltando hoje: responder por e-mail (comentário / resposta) --- alguns outros foram implementados a partir de hoje.

A ferramenta migrate from github e Comments on diff lines está pronta.

Necessita de personalização do modelo de correio
Veja # 6037

Portanto, já é possível personalizar um pouco do modelo - a linha de assunto é a única coisa que acho que não temos.

O que realmente deveríamos fazer, no entanto, é habilitar o i18n para e-mail e as mensagens git serv hook.

É necessário reverter uma solicitação de pull.
Veja # 6375

Suporte total de tags na IU. Criar, atribuir, alterar, excluir, etc. Eu realmente sinto falta desse recurso.

Sou a favor de config em banco de dados (com cli ou api para configurá-lo, como criar usuário e autenticação ldap, etc.) e sistema de plugins.
Esses dois devem empurrar o gitea um grande passo à frente.

LFS

• [x] Precisamos de alguma forma de gerenciar arquivos LFS em um repositório - no momento, eles são totalmente opacos # 7199 é uma tentativa de fornecer isso - mas para ser eficiente provavelmente precisa ...
  
  
  
  • [] Filtro Bloom para pesquisa de blob - seria muito bom ter uma maneira ligeiramente eficiente de encontrar o commit e em qual caminho de árvore que introduziu um blob
  
  
• [] No momento, não há uma maneira confiável de reiniciar um upload para o LFS - portanto, uploads muito grandes podem falhar repetidamente. Implemente tus.io de acordo com # 1723
• [] Devemos fornecer uma opção para usar apenas .gitattributes para determinar se um arquivo é um ponteiro LFS ao invés de apenas assumir que qualquer arquivo que se pareça com um ponteiro é um ponteiro. Embora isso provavelmente torne a funcionalidade do # 7199 muito difícil ...
• [] Os arquivos LFS devem ser visualizados na visualização diff.

Endurecimento

Desligamento e o início de tornar o Gitea realmente agrupável

• [] Precisamos fortalecer a resposta do Gitea ao desligamento.
  
  
  
  • [x] Isso significa desligamento normal de conexões de escuta, particularmente o SSH embutido - que atualmente pode causar corrupção de repositórios git por meio de desligamento abrupto. # 7274 é o início de uma tentativa de corrigir isso.
  
  
  • [] mas também significa que notificações, como tarefas, precisam ser serializáveis ​​- por exemplo, as filas de indexação devem passar por filas em disco ou db, filas de correio semelhantes, etc. Já temos alguns deles, mas essas filas não desligam normalmente.
  
  
• [] Como corolário do anterior, devemos separar a ação de indexar de pesquisar. O desligamento normal exige isso em qualquer caso - mas é parte da etapa em direção ao clustering. Não tenho certeza de qual arquitetura devemos usar, mas existem várias opções - separe o indexador em um processo separado e faça com que o Gitea seja somente leitura do índice ou exporte toda a indexação.

Diff e leitura de dados de comprimento arbitrário na memória

• [] O código Diff precisa de refatoração - é frágil, lê todo o diff na memória e requer que grandes diffs sejam analisados ​​pelo navegador antes que o usuário possa responder. Isso requer alterações na interface do usuário e no servidor - presumivelmente, uma rolagem infinita apoiada em Ajax é a técnica correta para isso. No momento, um diff grande o suficiente pode derrubar o servidor e o navegador.
• [] Nossa arquitetura diff atualmente polui o repositório base com ramos e objetos pré-mesclados.
• [] Em geral, DEVEMOS parar apenas de ler dados de comprimento arbitrário na memória. Se houver um lugar onde o navegador pode querer isso - devemos limitar o que lemos e, em seguida, usar uma técnica de rolagem infinita ou link completo com renderização do navegador ou renderizado em um pipeline para garantir que não seja armazenado em buffer inteiramente na memória. Mesmo códigos relativamente novos ainda sofrem com esse problema.
• [] (Se estivermos executando um processo git que pode retornar dados arbitrariamente longos, devemos tentar evitar ler todos eles diretamente em um buffer stdout inteiramente, mas fazer mais pipelines de rotina.)

Unir

• [] Devemos refatorar merge para usar o índice git inteiramente, pois atualmente fazemos uma verificação esparsa para mesclagem - basicamente porque git merge cairá para https://git-scm.com/docs/git-merge-one-file para lidar com mesclagens não aceleradas. Isso força a criação de caminhos semi-arbitrários no servidor - que são desnecessários e dependem dos fatores do conjunto de caracteres / sistema de arquivos. Não é necessário fazer isso - podemos fazer essas mesclagens com arquivos temporários, hash e adição ao índice diretamente.

Locais de fuga e repositório

• [] Devemos verificar em todos os lugares para escapar. Em geral, o código legado do Gogs era mal escapado e era responsável por vários problemas de segurança.
• [] A suposição de que o nome de usuário e os nomes do repositório não precisam de escape está nos forçando a tomar uma decisão de arquitetura de que não precisamos. Ele nem mesmo nos protegeu adequadamente para assinaturas git, portanto, # 5774.
• [] Embora seja agradável para os usuários que a localização do repositório subjacente corresponda à localização do sistema de arquivos - por exemplo, $GITEA_ROOT/owner/reponame é uma má decisão arquitetônica IMHO e leva a suposições dos usuários de que nossos repositórios ainda podem ser usados ​​pelo git no servidor sem pensamento adicional - ELES NÃO DEVEM. Devemos mover para $GITEA_ROOT/repository-$ID , possivelmente fragmentado. (Isso permitiria a remoção de muitas chamadas para repo.MustOwner() ou repo.GetOwner() )
  
  
  
  • [] Uma vez que passamos para o acima e estamos escapando de tudo corretamente, podemos então relaxar as restrições nos nomes de usuário e nomes de repositório - embora isso tenha que ser cuidadosamente pensado para garantir que o façamos de uma forma que não permite fingindo através de problemas semelhantes ao # 5774.
  
  
• [x] Devemos aplicar os processos git do servidor para que sejam executados com um ambiente Gitea suficiente - há usuários repetidos que tentam usar os repositórios do Gitea no servidor sem passar pelo Gitea, então reclamam que o Gitea não está atualizado etc. # 6961 é um etapa necessária para isso e após a fusão deste, simplesmente alteramos https://github.com/go-gitea/gitea/blob/bf552761894dee08f734d91f5c8175cd0cb2f9f5/cmd/hook.go#L72 para impor a configuração de SSH_ORIGINAL_COMMAND ou de outra forma impor que o resto do ambiente padrão é definido.
• [] Devemos ser capazes de lidar com repositórios montados NO_EXEC - e de fato, provavelmente deveríamos recomendar isso. Provavelmente não é realmente difícil de fazer - simplesmente altere a variável .git/config ou a variável central .gitconfig core.hooksPath e pense sobre onde colocaremos os ganchos de outra forma.
• [] Basicamente, estamos armazenando linhas de código diretamente no banco de dados para comentários - o que não funciona se os dados armazenados não estiverem em UTF-8. Isso significa que você simplesmente não pode comentar sobre um código não UTF8.

API / SDK

• [] É uma loucura a quantidade de trabalho que temos que fazer para construir uma API quando fazemos todo o esforço para ter arrogância. Devemos apenas autogerar isso a partir da arrogância, ou autogerar o máximo possível
• [] Não temos como testar uma versão fixa da API em relação ao nosso Gitea de desenvolvimento, então não podemos dizer quando estamos fazendo alterações significativas.
• [] Devemos ser capazes de usar uma API / SDK gerada automaticamente para criar sistemas de teste simples

Testando

• [] Atualmente executamos nossos testes de unidade no nível TRACE - isso limita nossa capacidade de adicionar rastreio adequado às coisas. Desde https://gitea.com/gitea/log/pulls/3 e se voltarmos para o Gitea, podemos mudar isso em nosso makefile.
• [] Precisa de mais testes de unidade e considere se alguns dos testes de integração são realmente de unidade e vice-versa. por exemplo, https://github.com/go-gitea/gitea/blob/master/integrations/download_test.go
• [] Precisamos de mais testes de integração que tentem rodar através de histórias de usuários. Isto é - um usuário efetua login, faz X, então Y e Z acontecem. É bom testar as coisas isoladamente, por exemplo. https://github.com/go-gitea/gitea/blob/master/integrations/download_test.go, mas isso não está realmente integrado e falta testar as experiências do usuário. Eu continuo dizendo isso, mas mais testes devem ser parecidos com: https://github.com/go-gitea/gitea/blob/master/integrations/ssh_key_test.go e https://github.com/go-gitea/gitea/blob /master/integrations/git_test.go que realmente testa se um recurso se integra corretamente.
• [x] Nosso regime de teste demora muito - o CI está levando de 30 a 40 minutos para ser executado no momento! Devemos executá-los em paralelo.
• [] Não existe uma maneira fácil de criar testes de migração.

Arquitetura do pacote Go

Modelos

• [] code.gitea.io/gitea/models depende de muitas coisas que isso tem que parar.
• [] models.x deve ser destruído. É uma decisão arquitetônica terrível.
• [] Para muitos dos modelos é muito fácil causar uma desreferência de ponteiro nulo porque você não sabe em que estado ele está. Podemos usar o sistema de digitação de go um pouco melhor aqui?
• [x] Devemos apenas colocar OwnerName na tabela de repositório, pois toda vez que obtemos um repositório, temos que ir e pegar o Proprietário. É bobo e uma perda de tempo. Repositórios não mudam de dono com frequência, então o custo de ter que lidar com isso não é grande.
• [] Muitas coisas ainda são feitas nos modelos e mais coisas deveriam ser removidas.
• [] Pode fazer sentido dividir os modelos em centrais e não centrais.

Módulos

• [x] Existem essencialmente dois tipos de módulos: aqueles que dependem de modelos e aqueles dos quais os modelos dependem. Vamos separar esses, um poderia ser chamado de serviços.

Macaron

• [] Acho que devemos levar a sério a mudança para o gim proposta por @lunny
• [] Nossa base de código está repleta de dependências no macaron, esse não deveria ser o caso

Configuração

• [] Depende do macaron também (!)
• [] Está intimamente ligado ao go-ini, outra dependência da qual devemos nos desconectar.

Internacionalização

• [] E-mail não internacionalizado
• [] Mensagens Git não internacionalizadas
• [] Mensagens de erro não internacionalizadas
• [] Devemos automatizar a remoção da documentação do nosso site hugo para que possa ser internacionalizado com CrowdIn
• [] É estranho que tenhamos os idiomas usando formas minúsculas, por exemplo, français, español nas listas do seletor de idioma - isso representa o início de uma frase em cada um desses idiomas, então AFAICS deve ser maiúsculo. Oui, si j'écris en français j'écris "français", mais si j'écris une liste á puces, j'écris:
  
  
  
  • inglês
  
  
  • Français
  
  
  • Espanhol
  
  

Gitea Dump & Restore

• [] Gitea dump é quebrado para conversão entre variantes SQL
• [] Não temos comando de restauração

Na parte da IU, sugiro entregar duas IU:

• um HTML simples (semelhante ao atual sem js)
• um JS completo que depende apenas de uma chamada de API. Isso forçaria a repensar algumas APIs, mas também permitirá mais interação de outro aplicativo externo.

• acho que devemos levar a sério a mudança para o gin proposta por @lunny

Eu sugeriria go-chi em vez de gim.

• Devemos automatizar a remoção da documentação do nosso site hugo para que possa ser internacionalizado com CrowdIn

IMHO o site / docs não deve ser traduzido de forma alguma, está sempre desatualizado ...

IMHO o site / docs não deve ser traduzido de forma alguma, está sempre desatualizado ...

Mas com crowdin, estar desatualizado notificaria as pessoas e invalidaria as traduções atuais.

Seria possível adicionar pacotes de SO adequados ao processo de construção? eu

Talvez pacotes no estilo PPA controlados e versionados pelos desenvolvedores GItea sejam uma boa ideia, mas eu não sou um fã do estilo Debian de "congelar e fazer backport de patches de segurança" de versão para projetos rápidos (como GItea)

Eu ainda gostaria de ter https://github.com/go-gitea/gitea/issues/3840.
Acho que pode ser implementado com compatibilidade com versões anteriores.
Mas isso ficará claro somente depois que a migração da nova biblioteca de roteamento for resolvida.
Uma limpeza / refatoração básica de pré-requisito tornaria isso mais fácil também.

Eu ainda gostaria de ter # 3840.
Acho que pode ser implementado com compatibilidade com versões anteriores.
Mas isso ficará claro somente depois que a migração da nova biblioteca de roteamento for resolvida.
Uma limpeza / refatoração básica de pré-requisito tornaria isso mais fácil também.

Nesse caso, é possível que você perca o suporte ao Drone, já que atualmente também não está implementado para Gitlab.

Eu ainda gostaria de ter # 3840.
Acho que pode ser implementado com compatibilidade com versões anteriores.
Mas isso ficará claro somente depois que a migração da nova biblioteca de roteamento for resolvida.
Uma limpeza / refatoração básica de pré-requisito tornaria isso mais fácil também.

Provavelmente não precisamos deste recurso de grupo para afetar os urls do repositório, poderíamos apenas criar pastas que o repositório pudesse ser colocado na tela, mas manter os repo urls iguais aos de agora

@tboerger
Achei que a URL pode permanecer a mesma se um repositório não estiver aninhado em um grupo / diretório.
Os URLs precisam ser "atualizados" apenas se o repo usar o recurso de grupo / diretório.
Mas sim, os repositórios com as novas URLs provavelmente não poderiam ter suporte para Drones pronto para uso.

@lafriks
Parece uma boa ideia. Meu cenário de uso do recurso é hospedar módulos Git ou subprojetos de projetos Repo. Portanto, não tenho certeza se cobre esse caso.

Sem problemas. Estou relutante em fazer uma mudança tão extensa, e possivelmente significativa, também.

Este assunto tem uma ideia muito boa e devemos mantê-los e resolvê-los.
No entanto, quando e como devemos escolher? Essa discussão pode durar para sempre.

Eu sugeriria que o proprietário escolhesse os assuntos ou uma votação entre eles e os membros.
O que você acha?

@DblK Isso mesmo. Mas acho que poderíamos fazer isso depois que migrarmos para gitea.com. Atualmente, precisamos de mais feedback dos usuários.

• Suporte mercurial
• melhor classificação e filtragem de relações públicas e problemas

• Suporte mercurial

Não por favor. É chamado de "git" e por um motivo.
Eu entendo o desejo de ter um escopo mais amplo, mas
o inchaço está ao virar da esquina ...

importação mercurial seria uma alternativa

Em 26 de julho de 2019, 13:52:50 UTC, Sandro Santilli [email protected] escreveu:

• Suporte mercurial

Não por favor. É chamado de "git" e por um motivo.
Eu entendo o desejo de ter um escopo mais amplo, mas
o inchaço está ao virar da esquina ...

-
Você está recebendo isto porque comentou.
Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/go-gitea/gitea/issues/6998#issuecomment -515461704

Solicitações / problemas / bifurcações de pull federados

Talvez não federado no sentido da palavra Fediverse (ActivityPub, OStatus, diáspora *, etc.), mas eu gostaria da capacidade de interagir com instâncias remotas de sua própria implementação da maneira que melhor se adeque ao projeto.

Já existe alguma discussão sobre isso em # 1612. ForgeFed coleta algumas idéias interessantes para obter federação em códigos forja como Gitea. Seria incrível se esse fosse o próximo grande recurso do Gitea!

Adoraria uma ferramenta de comparação visual para arquivos gráficos (JPEG, PNG, mas também PDF), semelhante ao que o Github oferece .

Já temos um PR para difundir as imagens

Já temos um PR para difundir as imagens

É verdade, mas isso não abrange a visualização do toque ou da transparência, apenas lado a lado. Além disso, não acho que abrange arquivos PDF. Estamos usando o Gitea aqui para o desenvolvimento de material gráfico (incluindo manuais e brochuras), e uma boa comparação visual para PDFs mudaria a vida.

Tenho algumas ideias que só quero apresentar: smile_cat:

1. Use o Cloud KSM para criptografar / descrever qualquer segredo de forma transparente. Isso protegerá contra o banco de dados hackeado e exposto. A ideia é que podemos usar um tipo personalizado com métodos de codificação / decodificação XORM para criptografar os dados secretos antes de gravar no banco de dados. Fizemos um exemplo de demonstração aqui: https://github.com/gomodules/ksm-xorm

2. Suporte OIDC: Retorna id_token além do token oauth2 quando conectado via Gitea

3. O perfil do usuário Gitea pode mostrar o perfil do usuário em qualquer repositório Git verificado. Exemplo: o usuário pode fixar repositórios Github / Gitlab / BitBuket / Gitea. A ideia é que os usuários também não possam ignorar os outros. Então, o gitea pode ser o único perfil de usuário global?

4. Suporte de domínio personalizado para repos (go)

5. Compatibilidade total com Github (vi alguns trabalhos nessa frente, não sei o quanto já foi feito).

6. Integração de servidor de linguagem opcional. Algo como Sourcegraph, como navegação embutida na IU.

Eu gostaria de contribuir com 1 e 2 em breve.

Talvez possamos mostrar o diff em uma forma de árvore de pastas e arquivos que mudaram - como no BitBucket, em vez de uma página enorme com todas as mudanças. Seria muito, muito mais legível.

Talvez uma opção para agregar notificações em todos os repositórios por dia ou por semana.
Uma espécie de resumo das atividades da semana passada.

Adicione a possibilidade de definir webhooks personalizados por meio de modelos personalizados e um conjunto de variáveis ​​padrão.

Não é uma evolução do Gitea, mas um projeto paralelo que seria útil: # 7853

Paridade de recursos com github!

Ou, pelo menos, uma lista atualizada no wiki, que mostra todos os recursos de que ainda precisamos antes de atingir a paridade. Essa seria uma boa maneira de estruturar esforços de desenvolvimento futuros.

@ lonix1 dê uma olhada em https://docs.gitea.io/en-us/comparison/ para essa lista

@kolaente parece que temos quase todas as marcas de escala! Isso!

Sou muito novo aqui, mas também sou um programador disposto; Eu adoraria se gitea suportasse gists. Esse é um dos maiores furos para o meu uso. Facilmente resolvido, mas eu prefiro apenas ter um sistema essencial no lugar.

Acho que o problema para gists seria https://github.com/go-gitea/gitea/issues/693 (vinculando, pois não parece ser referenciado a partir daqui ainda).

Adicione também Help documentação, que pode ser acessada pelo link Help . A fonte inicial para esta documentação pode ser a Ajuda do

A ajuda do

1. Criação de problemas por e-mail (consulte o service desk do GitLab).

Se mais pessoas começarem a adotar a auto-hospedagem para compartilhar seus projetos de código aberto, deve haver uma maneira de usuários não registrados enviarem problemas sem ter que criar uma conta em cada instância (a maioria das pessoas é extremamente improvável de se registrar para um bug relatório).

1. Algo semelhante ao AutoDevOps do GitLab. Isso significa a capacidade de definir um trabalho de CI padrão quando nenhum arquivo yaml de CI está no repositório.

2a. Guia e autenticação da IU do Container Registry.

1. Bots
2. GPG para web commits
3. Capacidade de bloquear mesclagens com base nas condições
4. Capacidade de criar arquivo na IU da web (incluindo em um repositório vazio em branco)
5. Gerenciar snippets anexados ao repo por meio da IU (consulte GitLab)
6. Suporte ao protocolo Git v2
7. Opção de IDE da Web aprimorada
8. Integração do Kubernetes (via plugin de IU a la GitLab)
9. Adicione um atraso de 400 ms antes que uma dica de ferramenta seja exibida ao passar o mouse
10. Melhor integração de CI (mostrar pipelines, suporte ao Concourse, etc)
11. Refinar IU
12. Aplicar 2FA
13. Bloqueio de arquivo
14. Encerrar automaticamente os problemas vinculados com a mesclagem de RP.

Algum tipo de plugin / sistema de extensão.

A maioria das sugestões são boas, mas criarão problemas na base de código principal.

Seria melhor ter plug-ins oficiais (e não oficiais). Isso também significa que os autores de plug-ins podem lançar com mais frequência.

@ lonix1 Bem, git hooks, webhooks e a API Swagger podem ser considerados pontos de conexão de plug-ins. Sou totalmente a favor de mais suporte para plugins, mas indicar uma lista com detalhes pode ajudar. Por exemplo, gostaria de suporte para um equivalente de linha de comando de webhooks.

@ guillep2k Por exemplo, todos os recursos de gerenciamento de projeto discutidos acima. Esses seriam muito úteis - mas provavelmente afetam tantas partes da base de código que 1) podem causar problemas até mesmo para aqueles que não usam esses recursos, e 2) por causa disso, esse desenvolvimento é muito lento porque os responsáveis ​​por mesclar novos recursos sabem que esse cenário é possível, por isso são cautelosos.

Se esses novos recursos pudessem ser lançados separadamente, eles poderiam ser experimentados por usuários antes de serem integrados ao branch principal.

E há outros exemplos desse tipo de grande recurso, basta rolar para cima.

Assinatura de @brandonkal GPG de commits gerados automaticamente agora é possível com a fusão de # 7631

Acho que o roteiro deve ser dividido nessas quatro categorias (adicionei alguns exemplos de problemas - deve ser óbvio que está longe de estar completo: wink :):

Funcionalidade básica

Ainda existem algumas _funções básicas_ que não estão funcionando corretamente.
Por exemplo:

• ele ainda precisa de uma boa solução de pesquisa, conforme mencionado em questões como # 5694 # 5277 # 3448, # 2967, # 2434, # 8366, # 8386 e # 7825
• o visualizador de PDF está quebrado
• o visualizador de SVG está quebrado
• parece que existem dependências não-livres usadas

Segurança

Existem também alguns problemas de segurança:

• [] [a imagem do Docker ainda é executada como root] (https://github.com/go-gitea/gitea/issues/1190) embora o guia do Docker seja muito claro sobre isso e não haja razão para usar o root user (você pode remapear as portas externas de qualquer maneira)
• [] [aplicar 2FA ainda não é possível] (https://github.com/go-gitea/gitea/issues/880)
• [] [Habilite a configuração de cabeçalhos CSP mais rígidos removendo estilos embutidos] (https://github.com/go-gitea/gitea/issues/305)
• [] [não há verificação se alguém tem permissão para acessar anexos] (https://github.com/go-gitea/gitea/issues/7908)

Integração

Acho que a integração com outros aplicativos / serviços é uma coisa boa em geral.
Porque o desenvolvimento de software geralmente não depende apenas de uma única ferramenta.
E provavelmente ajudará a convencer algumas pessoas a usar o Gitea em seu local de trabalho.

Esses dois problemas melhorariam muito a interoperabilidade:

• [] integrar automaticamente Drone CI / CD ( como @BNolet proposto anteriormente )
• [] [Integração de API para análises de RP automatizadas] (https://github.com/go-gitea/gitea/issues/5733) por meio de ferramentas como Pronto
• [] [fácil integração com um Container Registry] (https://github.com/go-gitea/gitea/issues/2316)
• [] uma solução genérica de webhook que permite aos usuários configurar webhooks personalizados facilmente ( como proposto por @bkcsoft anteriormente )

Além disso, webhooks genéricos evitariam a necessidade de outras pessoas conhecerem os detalhes internos do gitea. @ guillep2k teve uma ideia maravilhosa de que uma integração de "comando externo" poderia ser feita de maneira semelhante à integração de webhook genérico .
: aviso: Isso provavelmente resolveria a maioria dos problemas sobre o que a maioria das pessoas neste problema deseja como 'suporte a plug-ins' . Porque isso permitiria chamar qualquer coisa que os usuários precisassem chamar. No entanto, @lunny acabou de mencionar que isso já é praticamente possível via git hooks. Só não tenho certeza se essa é realmente a melhor maneira de integrar outras ferramentas / plug-ins / serviços.

Recursos no topo

Além disso, obviamente, existem alguns recursos interessantes em aplicativos concorrentes (por exemplo, Git [Hub / Lab]) (a maioria deles é provavelmente muito bom ter):

• [] [Reverter PRs] (https://github.com/go-gitea/gitea/issues/6375)
• [] [Diferença aprimorada para coisas não textuais, conforme mencionado por @ arthur-bauer] (https://github.com/go-gitea/gitea/issues/6998#issuecomment-516325459)
• [] [edições dos mantenedores] (https://github.com/go-gitea/gitea/issues/717)
• [] [Questões confidenciais] (https://github.com/go-gitea/gitea/issues/3217)
• [] mostrar mais detalhes do repositório (ou seja, tamanho do repositório , gráfico de contribuidores , barra de idiomas )
• [] algumas melhorias wiki (# 823 # 574)
• [] [tendo uma diferença como BitBucket conforme mencionado por @SignumPL] (https://github.com/go-gitea/gitea/issues/6998#issuecomment-517151615) (eu não sabia disso antes, mas parece realmente útil )
• [] [integrar uma funcionalidade como Octotree] (https://github.com/go-gitea/gitea/issues/3045#issuecomment-546233388)

Pode ser usado o banco de dados Oracle como opção? Se for possível tecnicamente.

@DemiusAcademius Se o xorm suportar melhor o oracle, acho que é possível.

Mais e mais pessoas estão começando a usar o Gitea, por exemplo, também causado pelo recente anúncio do rastreador GitLab. Mas o GitHub / GitLab ainda tem o efeito de rede do lado deles.

A federação seria um grande impulsionador para melhorar a capacidade de colaboração entre usuários de diferentes instâncias Gitea e, assim, aumentar toda a rede Gitea: # 1612

A capacidade de mostrar grandes diferenças na IU foi relatada como um fator limitante na adoção do Gitea.
Tickets que tratam disso: # 7341 (recurso), # 7495 (bug crasher)

A capacidade de mostrar grandes diferenças na IU foi relatada como um fator limitante na adoção do Gitea.
Tickets que tratam disso: # 7341 (recurso), # 7495 (bug crasher)

Essa é uma limitação _grande_. IMO tudo @alexanderadam listado acima empalidece em comparação com isso. Se eu não posso revisar grandes diferenças comentando in-line no código, isso é um grande problema.

W / R / T a raiva contra a Microsoft e Github que causou a migração de muitos projetos e causou alta demanda por federação - Gitlab recentemente propôs banir funcionários na China e na Rússia, 2 dos maiores países do mundo em massa territorial e economia. Os militares dos EUA mudaram o foco para a China e a Rússia (entre outros) para enfraquecer as barreiras que representam para a expansão / interesses imperiais dos EUA. Propaganda e incentivos financeiros trouxeram Microsoft (Github, Azure), Amazon, Google, Atlassian (Trello, Jira) e até Gitlab para as indústrias de guerra, espionagem, propaganda e vigilância em um papel ofensivo.

Trago isso para agradecer àqueles que trabalham em repositórios remotos de código aberto altamente disponíveis, com poucos defeitos nos serviços corporativos e vinculados ao Pentágono que usamos e nos quais ainda dependemos agora - e para chamar sua atenção de que alternativas rápidas são desaparecendo para aqueles que desejam usar a Internet e a tecnologia tão longe do império mais poderoso e hostil da história.

Talvez o tópico seja grande o suficiente para que uma seção separada do site oficial acompanhe o progresso desse recurso, junto com uma campanha separada de arrecadação de fundos para atender a essa demanda. Incluir o ForgeFed na arrecadação de fundos pode ser benéfico e justo, vendo o trabalho deles até agora. Já se passaram 17 meses desde o início da Microsoft sobre o Github, e espero que em mais 17 meses possamos estar usando o Gitea federado ou ter partes restantes do 'patrimônio líquido sendo construído.

Por favor, não discuta política aqui, vamos continuar no assunto - melhorar o Gitea para todos

@lafriks Melhorar o Gitea significa definir um nicho - algo não atendido por produtos substitutos. Marketing é o processo de localização de oportunidades externas, sendo "política" uma das quatro categorias principais de análise de marketing. Uma marca inteligente atrai os _valores_ das pessoas tanto quanto oferece recursos, especificações e preço. Há uma atração baseada em valores ("política") para alternativas como Gitea, e deixar de sublinhá-la e mantê-la seria uma falha em entender seu consumidor e a oportunidade de mercado.

"Político" como um termo tornou-se um clichê que encerra o pensamento, extinguindo a discussão sobre racismo, violência e exploração. Eu simplesmente vim aqui para agradecer às pessoas por continuarem a trabalhar em alternativas não associadas aos campos de concentração dos EUA, vigilância por rede de arrasto e outros interesses imperialistas nos quais a maioria de nossa indústria está ajudando ativamente. Se você está dizendo que essas não são qualidades que a Gitea defende, Entendi errado e vou embora.

Nota para @OKNoah

Marketing 101 para um projeto de código aberto:

1. Não fale sobre campos de concentração
2. Não mencione política
3. Tire o chapéu de papel alumínio
4. Não use termos antigos, como imperialismo
5. Conheça a vantagem do seu produto. A vantagem do Gitea é sua simplicidade.

Se a transparência do GitLab.com ofende você, você pode hospedar o GitLab-FOSS. É um produto multifuncional extremamente bom. Mas se você deseja uma instalação simples ou requer menos uso de memória em comparação com GitLab ou GitHub Enterprise, Gitea é uma boa opção para os recursos básicos da web.

Este tópico discute recursos que podem ajudar a fechar essa lacuna sem comprometer a simplicidade.

Meus 2 centavos - acho que este tópico ficou muito longo, e é hora de abrir uma nova edição resumindo todas as ideias já expressas aqui. E feche este.

Se você está dizendo que essas não são qualidades que Gitea defende, entendi errado e vou embora.

Não é isso que está sendo dito. O que está sendo dito é que este tópico é o lugar para discutir quais mudanças / melhorias no Gitea podem ser feitas (especificamente as técnicas). Essas discussões são mais do que bem-vindas, mas não neste tópico específico.

Como um dos leads, estarei bloqueando este tópico, como @XVilka disse certo, solicitamos muitos comentários e agora ele deve ser avaliado para as próximas etapas.

Poderíamos mudar o caminho para a conformidade com FHS para v2. Já é possível com sinalizadores, mas deve ser o padrão para v2.