Migrarse de GitHub a Codeberg, un método para gente floja

• Al mover algunos proyectos de GitHub a Codeberg, se resume cómo empezar la migración con el mínimo esfuerzo
• Mediante la función de importación de repositorios de Codeberg, es posible una migración completa que incluye issues, PR y releases, y la UI y el flujo de trabajo son similares a los de GitHub
• El hosting de páginas estáticas puede sustituirse con codeberg.page, y también existen alternativas como grebedoc.dev o statichost.eu
• La mayor dificultad es configurar el entorno de CI, ya que hay que renunciar a los runners de macOS y a la capacidad de ejecución gratuita de GitHub, pero se puede reemplazar con Forgejo Actions o Woodpecker CI
• Después de la migración, se propone mantener el repositorio de GitHub como archivo de solo lectura o hacer mirroring, para no cortar por completo la conexión con el ecosistema open source

---

Proceso de migración de GitHub a Codeberg

• A partir de la experiencia de haber empezado a migrar algunos repositorios de GitHub a Codeberg, se explica la dificultad real y la comodidad del proceso de migración
  • Aunque se había pospuesto pensando que Codeberg aún no estaba suficientemente listo, según el proyecto la migración puede ser sorprendentemente sencilla
  • El objetivo no es una configuración perfecta, sino encontrar la forma más fácil de empezar a migrar

• Migración de repositorios e issues

  • Codeberg ofrece una función de importación de repositorios de GitHub, que permite migrar junto con los issues, PR, releases y sus artefactos
    • En este proceso, los números de issue, etiquetas e información del autor se conservan tal cual
    • La UI de Codeberg es casi igual a la de GitHub, y ofrece una experiencia mucho más simple que los procedimientos complejos que suelen requerirse al migrar de otros issue trackers a GitHub

• Hosting de páginas estáticas

  • Si se usaba GitHub Pages, codeberg.page puede utilizarse como reemplazo
    • Aunque no existe una garantía oficial de disponibilidad (SLO), se menciona que en la práctica no se ha experimentado downtime
    • Funciona empujando HTML a una rama, con una estructura similar a GitHub Pages
    • Como alternativas, también se pueden usar grebedoc.dev o statichost.eu

• Dificultades del entorno de CI (integración continua)

  • La parte más complicada durante la migración es configurar el entorno de CI
    • GitHub ofrece runners gratuitos de macOS y capacidad de ejecución ilimitada para repositorios públicos, pero en Codeberg hay que renunciar a eso
    • Como solución, se puede recurrir a la cross-compilación por lenguaje y al self-hosting de runners de Forgejo Actions

  • Forgejo Actions vs Woodpecker CI

    • En Codeberg, Woodpecker CI es más estable, pero Forgejo Actions ofrece un entorno más familiar para quienes usan GitHub Actions
    • La UI y la sintaxis YAML son casi idénticas, y la mayoría de los workflows existentes de GitHub Actions funcionan sin cambios
    • Como ejemplo, lo que en GitHub Actions se usaba como uses: dtolnay/rust-toolchain en Forgejo Actions puede cambiarse por uses: https://github.com/dtolnay/rust-toolchain
    • Actualmente, la documentación de Forgejo Actions en Codeberg no está actualizada, y existe un PR relacionado

  • Cuando se necesita un runner de macOS

    • Si de verdad hace falta un build en macOS, se puede seguir usando GitHub Actions y hacer mirroring de los commits desde el repositorio de Codeberg hacia GitHub
    • Es posible configurar Forgejo Actions para que haga polling de la API de GitHub y sincronice el estado de CI con Codeberg
    • También se probaron otros servicios de CI que ofrecen builds en macOS, pero la integración con Codeberg no resulta más sencilla que con GitHub Actions

• Qué hacer con el repositorio de GitHub

  • Después de migrar, se modifica el README del repositorio de GitHub y se lo archiva
    • También se puede configurar para empujar commits desde Codeberg hacia GitHub, pero en ese caso los usuarios todavía pueden abrir PR y comentar en los issues
    • Algunas personas desactivan la función de issues en el repositorio de GitHub, pero entonces todos los issues desaparecen con error 404 y los PR no se pueden desactivar
    • Como ejemplo, el repositorio libvirt/libvirt usa una GitHub Action que cierra automáticamente todos los PR
  • Este enfoque puede tener efectos negativos en el self-hosting y en el ecosistema open source en general
    • Los usuarios pierden motivación para mejorar la optimización de builds o la frecuencia de descarga de archivos de release
    • Durante el periodo de transición, también puede considerarse mantener un mirror de solo lectura o seguir usando en paralelo GitHub Pages y Actions

[GN⁺]

Opiniones en Hacker News

• No me desagrada Codeberg en sí, pero no es un reemplazo completo de GitHub
  Tiene muchas limitaciones para subir repositorios de código personal o scripts de prueba, y los repositorios privados están limitados a 100 MB
  Tampoco permite alojar una página web como GitHub Pages. Para ese tipo de uso, una alternativa realista es hacer self-hosting de Forgejo
  Todo eso está bien resumido en el FAQ de Codeberg

  • En Codeberg también se puede alojar una web con la función Codeberg Pages
  • Yo también tengo mi sitio web corriendo en Codeberg Pages. La información de arriba es incorrecta → documentación de Codeberg Pages
  • Me cuesta estar de acuerdo con eso de que “administrar tu propio servidor git es una carga”. Si solo quieres un lugar para hacer push de código, con un servidor SSH basta
  • El proyecto Code Storage de Pierre me parece interesante como un servidor git tipo API que reduce esa carga operativa
  • (Aprovechando para promocionarlo) estoy desarrollando una alternativa a GitHub llamada Monohub. Incluye repos privados por defecto y también soporta PR. Ejemplo de repositorio público

• La razón por la que subo proyectos OSS a GitHub es simple: la comunidad está ahí
  Si solo fuera por alojar código, lo hospedo directamente por SSH o SFTP

  • Que la comunidad siga solo en GitHub es un problema de qué fue primero, el huevo o la gallina. Al final alguien tiene que moverse primero a otra plataforma para que el ecosistema cambie
    Yo subo todo solo a mi instancia personal de Gitea y no me preocupo por estrellas ni promoción
  • Quedarse en GitHub significa que la comunidad FOSS acepta una dependencia cerrada. De hecho, las políticas de GitHub están haciendo que la gente se vaya
  • En algunos proyectos ni siquiera puedes participar sin una cuenta de GitHub. Por ejemplo, este issue de crates.io sigue sin resolverse desde hace 10 años, y Reservoir de Lean exige al menos 2 estrellas en GitHub. Parece un refuerzo de la dependencia de Microsoft
  • GitHub ofrece muchos recursos de CI gratis. En especial, casi no hay alternativas a los runners de macOS. Gracias a eso se puede probar en muchos entornos distintos
  • Yo también empecé a hostear Git en un homeserver para salir de GitHub, pero desapareció la dopamina de hacer push de commits como antes. Siento que el open source perdió parte de su encanto al volverse más comercial

• Yo manejo todos mis proyectos personales con Forgejo self-hosted. No extraño GitHub para nada
  Incluso puedes restringir el acceso con Tailscale y bloquear crawlers de IA

  • Yo también llevo años corriendo Forgejo por mi cuenta. Incluso escribí un tutorial de instalación y hace poco migré a dos Raspberry Pi en Hetzner. Es más rápido y estable que GitHub
  • Antes usaba GitLab, pero Forgejo es mucho más ligero al ser un binario único en Go, así que consume menos recursos. Se puede correr fácilmente con Docker, y además es divertido hackearle funciones directamente
  • Instalé Forgejo cuando en GitHub bloquearon la creación de cuentas agente, y en 15 minutos agregué yo mismo la función de ocultar archivos “Viewed” en la revisión de PR
  • Hace poco varios proyectos grandes de OSS se pasaron a Forgejo y yo hice lo mismo; hasta ahora estoy muy satisfecho
  • Yo también instalé un runner de Forgejo con Docker para correr CI. Tiene su propio registro, así que despliego la app como imagen Docker

• Creo que cada vez será más importante evaluar alternativas a GitHub
  Pero GitHub ya impuso el estándar de CI y builds multiarquitectura, así que a las alternativas impulsadas por la comunidad les cuesta competir

  • El CI no tiene por qué depender de GitHub. En realidad, la mayoría de los sistemas de CI son solo ejecutores de comandos. Para equipos pequeños, incluso se puede operar perfectamente sin CI
  • No entiendo por qué sería irracional operar tu propio CI. Separar el repositorio y el CI no tiene ningún problema
  • Para mí, más importante que el CI es la experiencia de PR y code review. GitHub sigue siendo incómodo en muchas cosas, y su sistema de issues parece de hace 20 años
  • Este tipo de capa centralizada al final viene de un deseo de control. También se puede desarrollar perfectamente con un flujo de trabajo distribuido y centrado en lo local

• GitHub ofrece muchas cosas “gratis”, pero a cambio probablemente las use para recolección de datos y entrenamiento
  Codeberg no soporta repositorios privados, así que tampoco puede impedir que Copilot raspe los repos públicos
  Según el FAQ de Codeberg, si necesitas proyectos privados recomiendan hacer self-hosting de Forgejo

  • Pero mi repositorio en Codeberg está configurado como privado. No parece ser algo completamente imposible

• En nuestra empresa migramos por completo de GitHub a GitLab self-hosted
  Lo pusimos detrás de Tailscale, así que no tenemos la carga de SSO, y los runners de CI corren en EKS y en un clúster de GPU. Puedo ayudar a quien esté considerando una migración parecida

  • Me da curiosidad si evaluaron Forgejo. GitLab es fuerte para CI/CD de nivel empresarial, pero para proyectos pequeños Forgejo parece una opción más ligera
  • También me pregunto si GitLab self-hosted soporta funciones como aprovisionamiento automático de usuarios (SCIM)

• No tiene mucho sentido simplemente decir “reemplacemos GitHub”. Hace falta un nuevo hábito y una nueva propuesta de valor
  Así como GitHub reemplazó a SourceForge, la próxima generación de plataformas tendría que conectar en tiempo real la escritura de código y la colaboración
  Por ejemplo, podría ser una estructura como Google Docs donde cada prompt genere un commit

  • Pero también hay un fuerte componente geopolítico. En Europa y otros lugares hay movimientos activos para evitar depender de la tecnología estadounidense
  • Con la reciente controversia de Copilot, la confianza se ha debilitado y está surgiendo una corriente de salida de GitHub
  • Para mí, más que las funciones, lo importante es la disponibilidad (uptime). Últimamente GitHub ni siquiera llega al 99 %

• Codeberg es idealista, pero en la práctica tiene problemas de estabilidad
  Como opera sin Cloudflare, es vulnerable a ataques DDoS y tiene caídas frecuentes. Cuando no puedes acceder al repositorio remoto en medio del desarrollo, es realmente frustrante

  • Yo uso GitHub o Codeberg solo para compartir código de forma asíncrona. Aunque el remoto se caiga, deberías poder seguir trabajando en local
  • No me gusta Cloudflare, pero en la práctica es indispensable para defenderse del tráfico de bots y los ataques. Los servicios alternativos terminaban bloqueándose más seguido o siendo inestables. Se siente mucho la brecha entre los principios y la realidad
  • Si ves el monitor de disponibilidad de GitHub, en los últimos 90 días ha estado alrededor del 90 %. De hecho, Codeberg es más estable
  • Mi servidor git personal también perdió rendimiento por el raspado indiscriminado de los crawlers de IA. Al final terminé bloqueando todas las IP de las principales empresas
  • La esencia de git es su carácter distribuido. Aunque el remoto se caiga, deberías tener la versión más reciente en local

• Casi no uso GitHub desde la adquisición por parte de Microsoft. De hecho, me gusta más el flujo de trabajo simple, basado en correo electrónico, de Sourcehut
  También creo que el CI basta con que sea basado en comandos que puedan ejecutarse localmente

• Los repositorios de código deberían tener por naturaleza una estructura distribuida y federada
  Gracias al sistema de firmas criptográficas de git (GPG/SSH), se puede separar la confianza en el repositorio de la confianza en los commits
  En el centro solo harían falta un servidor de claves y la gestión del namespace, y el resto se puede distribuir

  • Radicle es precisamente un proyecto que busca ese tipo de hosting git distribuido
  • Pero la mayoría de los desarrolladores no sabe manejar bien sus claves de firma
  • Por eso se están integrando en Forgejo protocolos federados como Tangled y ForgeFed
  • git-bug también me parece un enfoque interesante. Aún no lo he probado, pero se ve prometedor