Migrando do GitHub para o Codeberg, do jeito para pessoas preguiçosas

• Ao mover alguns projetos do GitHub para o Codeberg, o texto organiza uma forma de começar a migração com o mínimo de esforço
• Com o recurso de importação de repositórios do Codeberg, é possível fazer uma migração completa, incluindo issues, PRs e releases, e a UI e o fluxo de trabalho são parecidos com os do GitHub
• A hospedagem de páginas estáticas pode ser substituída por codeberg.page, e também existem alternativas como grebedoc.dev e statichost.eu
• A maior dificuldade é montar o ambiente de CI, pois é preciso abrir mão dos runners macOS e da cota gratuita de execução do GitHub, com possibilidade de substituição por Forgejo Actions ou Woodpecker CI
• Depois da migração, a proposta é manter o repositório no GitHub como arquivo somente leitura ou espelho, para não cortar completamente a conexão com o ecossistema open source

---

Processo de migração do GitHub para o Codeberg

• Com base na experiência de começar a migrar alguns repositórios do GitHub para o Codeberg, o texto explica o nível real de dificuldade e a praticidade do processo de migração
  • O autor vinha adiando a mudança por achar que o Codeberg ainda não estava pronto o suficiente, mas, dependendo do projeto, a migração pode ser surpreendentemente simples
  • O objetivo não é uma configuração perfeita, mas sim encontrar a maneira mais fácil de começar a migração

• Migração de repositórios e issues

  • O Codeberg oferece a função de importação (import) de repositórios do GitHub, permitindo migrar junto issues, PRs, releases e seus artefatos
    • Nesse processo, números das issues, labels e informações dos autores são preservados
    • A UI do Codeberg é quase idêntica à do GitHub, oferecendo uma experiência muito mais simples do que os procedimentos complexos normalmente necessários ao migrar de outros issue trackers para o GitHub

• Hospedagem de páginas estáticas

  • Para quem usava o GitHub Pages, é possível usar codeberg.page como substituto
    • Não há garantia formal de disponibilidade (SLO), mas o autor comenta que, na prática, não chegou a enfrentar downtime
    • O funcionamento consiste em fazer push do HTML para uma branch, em uma estrutura semelhante ao GitHub Pages
    • Como alternativas, também é possível usar grebedoc.dev ou statichost.eu

• Dificuldades com o ambiente de CI (integração contínua)

  • A parte mais complicada da migração é montar o ambiente de CI
    • O GitHub oferece runners macOS gratuitos e capacidade de execução ilimitada para repositórios públicos, mas no Codeberg isso precisa ser abandonado
    • Como solução, é possível usar cross-compilation por linguagem e self-hosting de runners do Forgejo Actions

  • Forgejo Actions vs Woodpecker CI

    • No Codeberg, o Woodpecker CI é mais estável, mas o Forgejo Actions oferece um ambiente mais familiar para quem já usa GitHub Actions
    • A UI e a sintaxe YAML são quase idênticas, e a maior parte dos workflows existentes do GitHub Actions funciona sem alterações relevantes
    • Como exemplo, em um workflow do GitHub Actions que usava uses: dtolnay/rust-toolchain, no Forgejo Actions basta trocar para uses: https://github.com/dtolnay/rust-toolchain
    • Atualmente, a documentação do Forgejo Actions no Codeberg não está atualizada, e há um PR relacionado a isso

  • Quando é necessário um runner macOS

    • Se o build em macOS for indispensável, é possível continuar usando o GitHub Actions e espelhar os commits do repositório no Codeberg para o GitHub
    • Também é possível configurar o Forgejo Actions para consultar a API do GitHub e sincronizar o status de CI com o Codeberg
    • O autor também testou outros serviços de CI com builds em macOS, mas a integração com o Codeberg não foi tão simples quanto com o GitHub Actions

• Como lidar com o repositório no GitHub

  • Depois da migração, o repositório no GitHub é arquivado após editar o README
    • Também é possível configurar o Codeberg para fazer push de commits para o GitHub, mas nesse caso os usuários ainda podem abrir PRs e comentar em issues
    • Algumas pessoas desativam a função de issues do repositório no GitHub, mas isso faz com que todas as issues passem a retornar 404, e não é possível desativar PRs
    • Como exemplo, o repositório libvirt/libvirt usa uma GitHub Action que fecha automaticamente todos os PRs
  • Essa abordagem pode ter efeitos negativos sobre o self-hosting e o ecossistema open source em geral
    • Os usuários podem perder a motivação para melhorar otimizações de build ou a frequência de download de arquivos de release
    • Durante o período de transição, também vale considerar manter um espelho somente leitura ou usar GitHub Pages e Actions em paralelo

[GN⁺]

Comentários do Hacker News

• Não desgosto do Codeberg em si, mas ele não é um substituto completo do GitHub
  Há muitas limitações para hospedar repositórios de código pessoais ou scripts experimentais, e os repositórios privados são limitados a 100MB
  Também não é possível hospedar uma homepage como no GitHub Pages. Para esse tipo de uso, uma alternativa mais realista é fazer self-host do Forgejo
  Isso está bem explicado no FAQ do Codeberg

  • No Codeberg também dá para hospedar uma homepage com o recurso Codeberg Pages
  • Eu mesmo mantenho meu site no Codeberg Pages. A informação acima está incorreta → documentação do Codeberg Pages
  • Acho difícil concordar com a ideia de que “rodar seu próprio servidor git é pesado”. Se você só quer um lugar para dar push no código, um servidor SSH já basta
  • O projeto Code Storage, criado por Pierre, é interessante como um servidor git em forma de API que reduz esse custo operacional
  • (Merchan) estou desenvolvendo uma alternativa ao GitHub chamada Monohub. Ela oferece repositórios privados por padrão e suporta PRs. Exemplo de repositório público

• O motivo de eu colocar projetos OSS no GitHub é simples — a comunidade está lá
  Se fosse só para subir código, eu hospedaria direto via SSH ou SFTP

  • O fato de a comunidade ficar só no GitHub é um problema de ovo ou galinha. No fim, alguém precisa migrar primeiro para o ecossistema se mover
    Eu publico só na minha instância pessoal do Gitea e não ligo para estrelas nem divulgação
  • Permanecer no GitHub é só a comunidade FOSS aceitando uma dependência fechada. Na verdade, as políticas do GitHub estão afastando as pessoas
  • Alguns projetos nem permitem participação sem conta no GitHub. Por exemplo, a issue do crates.io continua sem solução há 10 anos, e o Reservoir do Lean exige pelo menos 2 estrelas no GitHub. Parece um reforço da dependência da Microsoft
  • O GitHub oferece muitos recursos de CI de graça. Especialmente runners de macOS, que quase não têm substitutos. Isso permite testar em vários ambientes
  • Eu também comecei a fazer hospedagem Git em home server para sair do GitHub, mas a dopamina de dar push em commits como antigamente sumiu. Dá a sensação de que o open source perdeu parte do encanto ao se comercializar

• Eu gerencio todos os meus projetos pessoais com Forgejo self-hosted. Não sinto falta nenhuma do GitHub
  Também dá para restringir o acesso com Tailscale e bloquear crawlers de IA

  • Eu também rodo Forgejo por conta própria há alguns anos. Até escrevi um tutorial de instalação e recentemente migrei para 2 Raspberry Pi na Hetzner. Está mais rápido e mais estável que o GitHub
  • Antes eu usava GitLab, mas o Forgejo é um binário único em Go muito mais leve, então consome menos recursos. Dá para rodar fácil com Docker e também é divertido hackear funcionalidades por conta própria
  • Instalei Forgejo quando o GitHub bloqueou a criação de contas de agente, e em 15 minutos adicionei eu mesmo a função de ocultar arquivos “Viewed” na review de PR
  • Recentemente vários projetos grandes de OSS migraram para o Forgejo, então fui junto, e até agora estou muito satisfeito
  • Eu também instalei um runner do Forgejo com Docker para rodar CI. Como ele tem registry próprio, distribuo meus apps como imagens Docker

• Acho que vai ficar cada vez mais importante avaliar alternativas ao GitHub
  Mas o GitHub acabou definindo o padrão de CI e builds multi-arquitetura, o que dificulta a competição de alternativas guiadas pela comunidade

  • CI não precisa ficar presa ao GitHub. Na prática, a maioria dos sistemas de CI é só um executor de comandos. Para equipes pequenas, dá para operar bem até sem CI
  • Não entendo por que operar CI por conta própria seria irracional. Separar repositório e CI não traz problema nenhum
  • Para mim, mais importante que CI é a experiência de PR e code review. O GitHub ainda é bem incômodo em vários pontos, e o sistema de issues parece parado há 20 anos
  • Essas camadas centralizadas no fim vêm de uma vontade de controle. Também dá para desenvolver de forma prazerosa com um workflow distribuído centrado no ambiente local

• O GitHub oferece muita coisa “de graça”, mas em troca há grande chance de isso ser usado para coleta de dados e treinamento
  O Codeberg não suporta repositórios privados, então também não dá para impedir que o Copilot vasculhe repositórios públicos
  Segundo o FAQ do Codeberg, se você precisa de projetos privados, a recomendação é fazer self-host do Forgejo

  • Mas meus repositórios no Codeberg estão configurados como privados. Então aparentemente isso não é totalmente impossível

• Nossa empresa migrou completamente do GitHub para GitLab self-hosted
  Colocamos atrás do Tailscale, então não há dor de cabeça com SSO, e os runners de CI rodam em EKS e em clusters com GPU. Posso ajudar quem estiver pensando em fazer uma migração parecida

  • Fico curioso se vocês chegaram a considerar Forgejo. O GitLab é forte em CI/CD de nível enterprise, mas para projetos menores o Forgejo parece uma opção mais leve
  • Também tenho curiosidade se o GitLab self-hosted suporta recursos como provisionamento automático de usuários (SCIM)

• Simplesmente dizer “vamos substituir o GitHub” não significa muita coisa. É preciso uma nova proposta de hábitos e de valor
  Assim como o GitHub substituiu o SourceForge, a próxima geração de plataformas precisa conectar escrita de código e colaboração em tempo real
  Por exemplo, poderia virar algo como o Google Docs, com um commit sendo criado a cada prompt

  • Mas também existe um peso grande de motivos geopolíticos. Em lugares como a Europa, há um movimento forte para evitar dependência de tecnologia dos EUA
  • Com a recente polêmica do Copilot, a confiança ficou abalada e surgiu um movimento de saída do GitHub
  • Para mim, mais importante do que funcionalidade é a disponibilidade (uptime). Hoje em dia o GitHub nem chega a 99%

• O Codeberg é idealista, mas na prática tem problemas de estabilidade
  Como opera sem Cloudflare, fica vulnerável a ataques DDoS e sofre com quedas frequentes. Quando você não consegue acessar o repositório remoto no meio do desenvolvimento, isso é realmente frustrante

  • Eu uso GitHub ou Codeberg apenas para compartilhamento assíncrono de código. Mesmo que o remoto caia, você precisa conseguir continuar trabalhando localmente
  • Não gosto da Cloudflare, mas na prática ela é essencial para se defender de tráfego de bots e ataques. Serviços alternativos costumavam bloquear mais ou ser ainda mais instáveis. Dá para sentir bem o choque entre princípio e realidade
  • Olhando o monitor de disponibilidade do GitHub, ele ficou perto de 90% nos últimos 90 dias. Na verdade, o Codeberg é mais estável
  • Meu servidor git pessoal também perdeu desempenho por causa de scraping indiscriminado por crawlers de IA. No fim, bloqueei todos os IPs das principais empresas
  • A essência do git é a descentralização. Mesmo que o remoto caia, a versão mais recente precisa estar no ambiente local

• Quase não uso GitHub desde a aquisição pela Microsoft. Gosto mais do workflow simples baseado em email do Sourcehut
  Também acho que CI basta ser algo baseado em comandos executáveis localmente

• Um repositório de código deveria ser, por natureza, uma estrutura distribuída e federada
  Graças ao sistema de assinaturas criptográficas (GPG/SSH) do git, dá para separar a confiança no repositório da confiança no commit
  Basta deixar no centro apenas um servidor de chaves e a gestão de namespace, e distribuir o resto

  • O Radicle é exatamente um projeto que busca essa ideia de hospedagem git descentralizada
  • Mas a maioria dos desenvolvedores não sabe fazer um bom gerenciamento de chaves de assinatura
  • Por isso protocolos federados como Tangled e ForgeFed estão sendo integrados ao Forgejo
  • O git-bug também é uma abordagem interessante. Ainda não usei, mas parece promissor