Gitea: Gitea hospedado Gitea

Muito boa ideia!

1,2 em fevereiro, 1,3 em abril, 1,4 em junho, 1,5 em agosto? deve ser tempo suficiente para implementar tudo isso 😄

Se você ainda não viu, um comentário fantástico e perspicaz apoiando sua abordagem de auto-hospedagem somente quando estiver pronto: https://lobste.rs/s/gokjbo/gitea_1_1_0_released/comments/dg9pwe#c_dg9pwe

@lunny Agora que penso nisso (obrigado @zellyn por esse link 😂 ) Por que precisamos de provedor oauth, suporte _completo_ webhook, documentação api e uma API _completa_ para auto-hospedagem?

O OAuth _Consumer_ é necessário (é mesclado AFAIK) para que as pessoas possam fazer login usando o github auth.
Drone só usa ganchos, então por que precisaríamos do outro?

Quanto à API, não sei por que a auto-hospedagem exige isso TBH :)

Concordo em cortar essa lista. A auto-hospedagem anterior provavelmente nos ajudará a definir melhor as prioridades :)

@bkcsoft talvez possamos configurar um site hospedado e tentar.

@bkcsoft Eu atualizei o problema, você quer dizer isso?

-> O provedor OAuth (#27) não está fechado

@ekozan não fechado, mas riscado da lista de "coisas que precisamos"

Adicionados "Limites de tamanho do repositório" já que não temos armazenamento ilimitado nos servidores...

Minha proposta de limites:

• 0 organizações
• 3 repositórios
• 1 GB/repositório

@bkcsoft Você quis dizer que será um serviço público para qualquer pessoa?

Talvez, talvez não, mas _se_ se tornar um serviço público não podemos tê-lo ilimitado ;)

Eu acho que o dogfooding é importante o suficiente para que os limites de tamanho do repositório não precisem estar no caminho crítico para o gitea auto-hospedado. Nos primeiros dias após a migração para o gitea, encontrei várias omissões de recursos que me fizeram pensar que a auto-hospedagem ajudará a concentrar o esforço em fazer essas coisas. O Gitea já é uma ferramenta fantástica, altamente utilizável e de alto desempenho - é uma pena que você não a esteja usando. ;-)

Em vez de depender de limites rígidos de tamanho, pode ser útil pensar em como o servidor auto-hospedado será administrado, quem vai policiar o mau comportamento e quais ferramentas eles vão querer. Por exemplo, forks de contribuidor do projeto gitea devem ser suportados no próprio servidor gitea. Isso expõe o risco de que um usuário faça um fork do gitea e, em seguida, empurre o warez para o fork. Os limites de tamanho podem ajudar a evitar o envio de binários grandes, mas podem não ajudar com uma lista de senhas ou números de cartão de crédito. Uma ferramenta que pode ajudar nesse caso é algo que detecta arquivos alienígenas por contagem de linhas diff ou hash contínuo.

Um bom efeito colateral de ter uma ferramenta de diff-size disponível é que o código pode estar disponível como uma opção para ser executado durante pushes para sinalizar commits legítimos que deveriam ter sido divididos em partes menores de qualquer maneira. (Discussão relacionada sobre maneiras de fazer isso: https://github.com/go-gitea/gitea/issues/3658#issuecomment-372263759.)

Aposto que há muitas outras coisas sutis que precisarão ser abordadas para servidores voltados para o público. Pode fazer sentido usar uma questão principal de "hospedagem pública" separada ou um marco para rastrear essas coisas.

Falando em marcos, esse problema deve ser adicionado ao 1.5.0?

@stevegt Não, pois acho que nem todos os PRs serão mesclados / resolvidos em 1.5.0.

Eu removi Repository Size Limits (#3658) do problema, pois ele não afetará o gitea hospedado no Gitea.

Eu removi o Repository Size Limits (#3658) do problema, pois ele não afetará o gitea hospedado no Gitea.

Excelente! Tenho certeza de que quanto mais cedo o Gitea se hospedar, mais rápido todo o projeto lucrará com as experiências da vida real e ganhará confiança :)

@lafriks menciona em outro tópico:

A auto-hospedagem provavelmente exigiria financiamento/patrocínio adicional para pagar por máquina virtual adicional

E @lunny pergunta acima:

@bkcsoft Você quis dizer que será um serviço público para qualquer pessoa?

Seria viável combinar esses pensamentos em um "Que tal criar um serviço Gitea online, onde as pessoas pagam por (digamos) repos privados?".

Se tudo bem, isso deve gerar os fundos para se pagar + as recompras públicas.

Como conceito, parece ser um terreno bastante percorrido. :sorriso:

Para adicionar prontamente à ideia do @justinclift ; o momento pode estar certo com as notícias atuais da Microsoft assumindo o GitHub.

@lafriks menciona em outro tópico:

A auto-hospedagem provavelmente exigiria financiamento/patrocínio adicional para pagar por máquina virtual adicional

Estou confiante de que haverá financiamento da comunidade ou patrocínio de organizações para tornar a hospedagem do gitea possível. Como o Gitea é amigável aos recursos (sim, GitLab, estou olhando para você), isso não será grande coisa.

@mxmehl até agora houve 5 indivíduos que contribuíram desde que o opencollective foi aberto no mês passado: https://opencollective.com/gitea

@justinclift, como o Gitea é puramente comunitário, não há como configurar repositórios privados pagos, pois isso exige criar uma empresa, lidar com impostos e ter uma equipe em tempo integral para lidar com problemas técnicos

@mxmehl até agora houve 5 indivíduos que contribuíram desde que o opencollective foi aberto no mês passado: https://opencollective.com/gitea

@techknowlogick Não conhecia esta página. Agora são 6 ;)

@lafriks Bem .... existem projectos comunitários ao redor - tanto para software e não de software coisas - que parecem gerenciar si ok, incluindo questões financeiras, coisas que eles pagam, o pessoal (quando necessário), e assim por diante.

Dito isto, requer um nível de vontade para fazer acontecer + mantê-lo. As pessoas em quaisquer funções necessárias também precisam ser boas guardiãs (confiáveis, confiáveis, inteligentes).

Se não houver interesse, então não vai a lugar nenhum de qualquer maneira. Idem se nenhum tipo de "guardião" adequado puder ser acordado.

A partir do link Open Collective mencionado acima, parece que algumas sementes iniciais estão em vigor. Isso demonstra que há pessoas ao redor que são consideradas boas como guardiãs. :sorriso:

@justinclift Não estou dizendo que não é possível, mas não no estágio atual, mas no futuro pode acontecer. Atualmente, pelo menos, eu me concentraria melhor no desenvolvimento de novos recursos do Gitea e na melhoria da documentação :) Portanto, qualquer ajuda é muito apreciada para avançar mais rapidamente para esse objetivo.

He he he he

Não se preocupe @lafriks. :sorriso:

O primeiro do objetivo é Gitea hospedado Gitea desde que o github se casou com a Microsoft. :)

Acho que apenas os números 2519 e 3748 precisam ser revisados ​​e mesclados antes de encerrarmos este problema.

@bkcsoft

Adicionados "Limites de tamanho do repositório" já que não temos armazenamento ilimitado nos servidores...

Minha proposta de limites:

• 0 organizações
• 3 repositórios
• 1 GB/repositório

Eu acho que, com o limite de quantidade de repos, podemos adicionar a configuração de fork apenas para repositórios existentes para todos os usuários que não fazem parte da equipe Gitea:

• 0 organizações
• 3 Repos (permitir apenas garfos)
• 1 GB/repositório

Eu não acho que a contagem de fork precisa ser limitada, ela seria limitada pela contagem do repositório gitea org de qualquer maneira, então isso deve estar ok.
Quanto ao tamanho do repositório, sim, provavelmente deve haver alguns limites

Devemos limitar a criação de organizações, a criação de repositórios, para que o limite de tamanho do repositório não seja um problema necessário para o Gitea hospedado no Gitea.

Podemos considerar adicionar #3134 e #4302 (PR e backlinks de emissão) à lista de pré-requisitos para auto-hospedagem - talvez eu seja único, mas nossa pequena instalação do gitea começou a ficar complicada sem esses backlinks assim que adicionamos mais de alguns usuários e problemas. Conseguimos contornar isso com a pesquisa de problemas, mas isso é limitado sem a pesquisa global de problemas (#2434/#3841).

@stevegt Embora seja bom ter backlinks, não os vejo bloqueando a mudança para auto-hospedagem :)

@bkcsoft Justo - pensei em mencioná-lo no caso de desencadear alguma realização. Em nosso caso local, desenvolvemos o hábito de adicionar manualmente os backlinks nos comentários do problema como uma solução alternativa.

Recentemente, ouvi sobre o esforço de https://teahub.io. Eles querem iniciar uma organização sem fins lucrativos. O Gitea não pode usar isso quando estiver pronto com a configuração?

@jlelse Não. O Gitea configurará um servidor autônomo (ou seja, self.gitea.io) para hospedar o gitea e espelhar no github, gitlab ou teahub e etc.

@lunny Nós realmente exigimos comentários em commits, já que atualmente estamos usando apenas comentários em PR no GitHub?

@JonasFranzDEV Quero dizer comentários sobre commits de PR, acho necessário.

Estou comentando aqui porque o #4108 está fechado. Quando o Gitea Patreon (ou alternativa semelhante ao Patreon) for lançado, eu preciso saber sobre isso. Estarei contribuindo. Eu gostaria de ver este projeto auto-hospedado e desenvolvido. Assim que eu mover todos os meus repositórios, não vou mais gastar dinheiro com o Github, vou comprometê-lo mensalmente com o Patreon.

@ryanburnette https://opencollective.com/gitea

@lunny parece que 'Sistema de aprovação' no início do tópico pode ser riscado. (As questões sendo respectivamente encerradas e mescladas)?

@mjmlvp Acho que você está certo. Eu removi o nº 996 nº 2519, pois não deve ser um bloqueio desse problema. Montaremos um servidor para hospedar nossos desenvolvimentos.

Alguma novidade sobre isso ?

Sim, ainda precisamos adicionar limitações de aprovação e, em seguida, podemos migrar para o código auto-hospedado

Seria bom adicionar os problemas em aberto para isso à lista. No momento, parece que todos os problemas e PRs vinculados foram fechados e mesclados.

@skddc feito.

para o registro

abrir servidores gitea

• https://try.gitea.io/
• https://teahub.io/
• https://dev.sum7.eu/

não confies em ninguém. faça backups regulares

@giteauser não consigo ver como isso é relevante

@giteauser e isso é sobre o desenvolvimento do gitea auto-hospedado, para que o desenvolvimento do gitea não precise mais acontecer no github. Eu ainda não consigo ver como isso é relevante.

Ah, eu postei isso para o problema errado, me desculpe.

Portanto, todos os recursos necessários devem ser implementados agora. Podemos ter uma nova versão e migrar?

Certo, vamos configurar uma instância do gitea para hospedar o desenvolvimento do gitea.

Acho que corrigir o problema de despejo de backup e adicionar a funcionalidade de restauração adequada também é uma parte importante para gerenciar a infraestrutura de um gitea auto-hospedado

Se você estiver implantando o Gitea no Kubernetes, posso recomendar o Ark para backups e restaurações.

De um modo geral, o backup não parece ser um tópico de bloqueio para o desenvolvimento de auto-hospedagem do Gitea, porque todos geralmente têm diferentes estratégias/programas de backup, dependendo de sua escolha de plataforma, método de implantação, ferramentas existentes, etc. deve ser apenas um problema de bloqueio para a prontidão de produção dessa instância.

@max-wittig O site auto-hospedado do gitea será executado em algum provedor de nuvem pública. Eles fornecerão serviço RDS e ferramenta de backup de banco de dados e alguma função de backup de disco para que o comando backup dump não seja um problema de dependência. O comando dump é para um serviço gitea de nó único. Claro que devemos corrigir esses problemas.

@skddc É uma ferramenta interessante que podemos considerar isso.

Eu realmente espero que a versão 1.8.0 seja a versão em que o gitea se torne auto-hospedado. Eu pessoalmente adoraria usá-lo para meus próprios projetos, mas só estou usando o gitea como um espelho pela simples razão de que não confio o suficiente se os desenvolvedores - vocês - nem o usarem para o desenvolvimento do gitea. Além disso, gostaria de propor o uso do gitea no meu ambiente de trabalho, mas não posso propor, pois apenas rirei quando disser: "oh btw, parece incrível, mas os desenvolvedores do gitea não usam para seu próprio projeto"...

Isso não é uma crítica ou uma forma de pressionar vocês. Apenas informando o que eu (e provavelmente muitos outros) acharia problemático quando se trata de usar o gitea como sistema de controle de código-fonte principal;)

Por último, para ser um pouco mais construtivo. Se você está procurando um vps clous muito bom (e barato) para backups ou até mesmo para hospedar o gitea, dê uma olhada no hetzner https://www.hetzner.com/storage/storage-box Embora para uma infraestrutura importante como o Gitea você provavelmente gostaria de fazer backup em dois locais completamente diferentes (digamos, hetzner e digitalocean, por exemplo).

@markg85 estamos trabalhando em https://gitea.com

Alguma atualização no gitea hospedado no gitea em gitea.com?

@zachdoty Ainda estamos trabalhando nisso.

Esqueci algo necessário para passar do github para o gitea. Precisamos mover todos os dados (incluindo dados do git, problemas, comentários, solicitações de pull do github para o gitea), mas na verdade não encontrei ferramentas adequadas para fazer isso. Enviei PR sobre mover o repositório de migração do frontend para o backend, veja #6200 , e também https://gitea.com/gitea/migrator deve ser mesclado ao gitea porque a API do gitea não permitirá criar problemas com o número do índice especificado.

O gitea-github-migrator pode migrar quase tudo, caso você ainda não o tenha encontrado. Se faltar algo, talvez possa ser adicionado lá, para que outros projetos também tenham uma boa ferramenta de migração.

@skddc eles realmente são os mesmos.

Ah, desculpe. Não tinha seguido o link.

Como @kolaente disse, convidamos @jonasfranz para mover gitea-github-migrator para gitea.com e eu mando um PR https://gitea.com/gitea/migrator/pulls/1 quer melhorar isso. Mas eu encontrei como uma ferramenta de terceiros, há uma desvantagem. Ou seja, é difícil manter o índice de problemas como antes. (Para deixar todos os links sobre o problema ainda disponíveis.) Então, acho que mesclar a ferramenta de migração no gitea na interface do usuário de migração é uma ideia melhor.

Definitivamente seria incrível se os links internos nos comentários etc. pudessem ser preservados. Também seria incrível se os PRs originários do mesmo repositório pudessem ser importados como PRs reais em vez de problemas!

Eu adicionei a nova tarefa Migrate a throughout github repository to gitea no conteúdo do problema e mudei para 1.9.0 para que isso não bloqueie o lançamento da v1.8. Mas não acho que devemos esperar até o lançamento da v1.9, já que o gitea.com seguirá o mestre.

A produção do Gitea.com está pronta, pois devo me preocupar em armazenar código lá e perdê-lo?

@BNolet , configuramos um cluster

Uau que fantástico! Todos vocês esperam poder ser uma alternativa completa ao GitHub ou Gitlab?

Acho que não. O principal objetivo do gitea.com é hospedar os próprios desenvolvimentos do gitea. Embora não tenhamos feito nenhuma limitação no gitea.com, recomendamos que você configure sua instância hospedada do Gitea, pois é muito fácil.

Algum motivo para não habilitar o login OpenID?

@lunny eu tenho um e adoro :D

Qual é a probabilidade de CI/CD se tornar parte do produto Gitea?

@strk apenas esqueça. Habilitará o login do OpenID.
O próprio

Obtendo um erro 500 ao tentar usar a opção Github oauth na página de login, depois de ir a solicitação de permissões para o aplicativo go-gitea no Github.

Devo esperar um pouco para verificar a instância principal?

@jakimfett esse é um problema conhecido. Você pode tentar duas vezes e está tudo bem.

@strk apenas esqueça. Habilitará o login do OpenID.

@lunny como ainda estava desligado hoje, talvez exista um script de implantação que continue desativando?

@jakimfett esse é um problema conhecido ...

Jogue uma edição com o número da edição e eu acompanharei lá.

_edit(ões): formatação_

Codeberg é um serviço gratuito baseado em Gitea. Talvez Gitea possa montar um espelho oficial lá. Atualmente está espelhado em https://codeberg.org/Codeberg/gitea.

O Gitea será hospedado em https://gitea.com/gitea/gitea , e movemos a maioria dos outros pacotes para https://gitea.com/gitea , e o próprio gitea está em andamento. Mirror é bem-vindo em qualquer outro serviço baseado em gitea.

@lunny comentou ontem:
Mirror é bem-vindo em qualquer outro serviço baseado em gitea.

Vou montar um espelho atualizado assim que voltar do meu fim de semana.

Relacionado:
Existe uma lista de espelhos em algum lugar, e eu me adiciono a ela, ou...?

@jakimfett Não existe, mas você pode criar um pr com uma nova página de documentos

Para um melhor manipulador de usuários ao migrar o gitea para longe do github, gostaria de mover isso para a v1.10 e acho que devemos implementar https://github.com/go-gitea/gitea/issues/7293 antes de começarmos a migrar.

Eu seria totalmente a favor dessa mudança se ela não estivesse hospedada na China ou o e-mail de ativação demorasse 10 minutos para chegar.

Eu seria totalmente a favor dessa mudança se ela não estivesse hospedada na China ou o e-mail de ativação demorasse 10 minutos para chegar.

Edit: aparentemente, eu estava incorreto.

de alguma pesquisa no Google, aparentemente o endereço IP do gitea.com está no Japão, não na China. Esse endereço IP é de propriedade do Alibaba.

Usamos mailgun.org para enviar e-mails. Não sei porque vai demorar 10 minutos.

Nosso provedor de nuvem de doações é a didiyun, que fica na China e fornece muitas máquinas. Não temos outra escolha atualmente.

E o primeiro propósito do gitea.com não se tornará um serviço como github.com ou gitlab.com. Ele hospedará apenas o próprio gitea e recomendamos que você configure a instância do gitea de fato.

@programmerjake Isso é um servidor de ponte.

Não era minha intenção sair da minha instância, mas não gosto que este projeto dependa de infraestrutura doada de uma empresa chinesa que quase não tem reputação no passado ou resultados de pesquisa. Você realmente não sabe o que eles farão no futuro ou se eles exigirão cortar sua doação se você não implementar XY ou ZA ou se eles simplesmente desaparecerem algum dia.
Você provavelmente sabe o que está fazendo e minhas preocupações são apenas cautelosas, mas você nunca saberá.

Por que uma empresa chinesa faria isso, mas uma empresa americana não? :)

E eu sou um chinês, e talvez você devesse ter cuidado. Algum dia eu posso roubar seus códigos. :)

Acho que posso ter esse plano quando comecei o Gogs com outros 3 chineses em 2014.

Não era minha intenção sair da minha instância, mas não gosto que este projeto dependa de infraestrutura doada por uma empresa chinesa. Você realmente não sabe o que eles farão no futuro ou se eles exigirão cortar sua doação se você não implementar XY ou ZA ou se eles simplesmente desaparecerem algum dia.
Você provavelmente sabe o que está fazendo e minhas preocupações são apenas cautelosas, mas você nunca saberá.

Essa é uma resposta totalmente idiota.
Agora eu posso ter a mente mais aberta já que sou holandês, nós meio que abraçamos isso. Você deveria tentar isso também.

Desde que este projeto seja de código aberto, não há risco, na minha opinião, por qualquer coisa que você disse.
E mesmo que o façam, o que provavelmente significa bifurcar o Gitea, eles estão totalmente no seu direito, pois a licença simplesmente permite.

Os EUA no entanto... deixe-me lembrá-lo que o Github limitou seus recursos agora devido à "guerra comercial" entre os EUA e a China. Se alguma coisa, os EUA são mais um risco para o desenvolvimento de software livre no momento do que a China já foi. Caramba, @lunny provavelmente foi afetado neste mesmo repositório devido à guerra comercial.

@lunny e a equipe que desenvolve o Gitea. Mantenha o trabalho incrível! :)

E o primeiro propósito do gitea.com não se tornará um serviço como github.com ou gitlab.com. Ele hospedará apenas o próprio gitea e recomendamos que você configure a instância do gitea de fato.

É algo que você pode considerar no futuro?

Desde que este projeto seja de código aberto, não há risco, na minha opinião, por qualquer coisa que você disse.

O projeto principal não tem risco, mas a infraestrutura sim. Não há garantias de que o doador desconhecido e sem reputação estará lá no próximo mês, não importa se ele vem de qualquer lugar ou da China. O GitHub estará aqui por um longo tempo e não irá a lugar nenhum tão rápido.

Além disso, se toda a infraestrutura se mudar para a China, toda a base de usuários sofrerá devido às dificuldades entre os EUA e a China.

@lunny Em relação aos e-mails que levam cerca de 10 minutos, no meu caso, o servidor da minha empresa tem uma medida anti-SPAM que é um cronômetro de "resfriamento" (20 minutos aqui) no qual ele rejeitará temporariamente quaisquer e-mails de fontes desconhecidas. Portanto, se for a primeira vez que um usuário (eu) recebe um e-mail desse domínio (por exemplo, gitea.com), meu servidor responderá com "tentar mais tarde" e lembrará dessa combinação de usuário/domínio. Na próxima vez que o gitea.com tentar entregar meu e-mail dentro do prazo esperado, o servidor aceitará a mensagem.
Obviamente temos algumas "fontes confiáveis" configuradas, como GMail, Hotmail, etc. que não precisam de um período de espera.

Pessoal, se você quiser mais infraestrutura espalhada por todas as regiões, vote com sua carteira em https://opencollective.com/gitea

@SuperSandro2000 Você está ciente de que Gitea não é um serviço, mas um _produto_? Você baixa os fontes, compila o Gitea em seus servidores e instala. Nenhuma conexão necessária com a hospedagem do Gitea.

se eles exigirem cortar sua doação se você não implementar XY ou ZA ou se eles simplesmente desaparecerem algum dia.

Não há garantias de que o doador desconhecido e sem reputação estará lá no próximo mês.

Algumas respostas para isso: não hospedaríamos em uma empresa sem reputação, e os líderes da Gitea depositaram nossa confiança nessa empresa. Se eles pararem de fornecer patrocínio ou deixarem de ser uma empresa, temos opções disponíveis para nós e podemos mudar para outro lugar.

toda a base de usuários sofrerá devido às dificuldades entre os EUA e a China.

Uma grande parte da equipe Gitea é da China (mas também temos mantenedores em todos os outros continentes também), e se a equipe de desenvolvimento não puder acessar o código, a base de usuários sofrerá, e é por isso que precisamos da equipe de desenvolvimento para poder acessar código. Construímos o Gitea para que todos possam usá-lo, mesmo usuários que foram banidos do GitHub (após a recente onda de banimento do GitHub, muitos desses usuários começaram a usar o Gitea).

Como outros já mencionaram, existem espelhos da base de código em outras instâncias ao redor do mundo e, graças ao git, há um registro de todas as alterações feitas no código para que todos possam ter visibilidade de todas as alterações.

Uma nota sobre transparência: bloqueei este tópico. Eu não quero parar esta conversa, no entanto, ela deve ser movida para um local diferente, pois este ticket do github é sobre quais aprimoramentos precisam ser feitos com software para auto-hospedagem (em vez de onde estamos hospedando).