Gitea: Gitea acogió Gitea

¡Muy buena idea!

1,2 en febrero, 1,3 en abril, 1,4 en junio, 1,5 en agosto? debería ser tiempo suficiente para implementar todo eso 😄

Si no lo ha visto, un comentario fantástico y perspicaz que respalde su enfoque de alojamiento propio solo cuando esté listo: https://lobste.rs/s/gokjbo/gitea_1_1_0_released/comments/dg9pwe#c_dg9pwe

@lunny Ahora que lo pienso (gracias @zellyn por ese enlace 😂) ¿Por qué necesitamos un proveedor de autenticación, soporte de webhook _completo_, documentación de API y una API _completa_ para el alojamiento propio?

Se requiere OAuth _Consumer_ (se fusionó AFAIK) para que las personas puedan iniciar sesión usando github auth.
Drone solo usa ganchos de empuje, entonces, ¿por qué necesitaríamos el otro?

En cuanto a la API, no estoy seguro de por qué el alojamiento propio requiere eso en absoluto TBH :)

Estoy de acuerdo en recortar esa lista. Es muy probable que el alojamiento propio más temprano nos ayude a establecer mejores prioridades :)

@bkcsoft tal vez podamos configurar un sitio alojado y probar.

@bkcsoft Actualicé el problema, ¿quieres decir eso?

-> El proveedor de OAuth (#27) no está cerrado

@ekozan no cerrado, pero

Se agregaron "Límites de tamaño del repositorio" ya que no tenemos almacenamiento ilimitado en los servidores...

Mi propuesta de límites:

• 0 organizaciones
• 3 Repos
• 1GB/repositorio

@bkcsoft ¿Quiso decir que será un servicio público para alguien?

Quizás, quizás no, pero _si_ se convierte en un servicio público no podemos tenerlo ilimitado ;)

Creo que dogfooding es lo suficientemente importante como para que los límites de tamaño de repositorio no necesiten estar en la ruta crítica para gitea autohospedado. En los primeros días después de migrar a gitea, me encontré con varias omisiones de funciones que me hicieron pensar que el alojamiento propio ayudaría a concentrar el esfuerzo en hacer esas cosas. Gitea ya es una herramienta fantástica, muy útil y de alto rendimiento; es una verdadera lástima que no la estén usando ustedes mismos. ;-)

En lugar de depender de límites de tamaño estrictos, podría ser útil pensar en cómo se administrará el servidor autohospedado, quién controlará el mal comportamiento y qué herramientas querrán. Por ejemplo, las bifurcaciones de contribuyentes del proyecto gitea deberían ser compatibles con el propio servidor de gitea. Esto expone el riesgo de que un usuario bifurque gitea y luego empuje warez a su bifurcación. Los límites de tamaño pueden ayudar a evitar el envío de archivos binarios grandes, pero es posible que no ayuden con una lista de contraseñas o números de tarjetas de crédito. Una herramienta que podría ayudar en ese caso es algo que detecta archivos alienígenas por conteo de líneas diferenciales o hash rodante.

Un buen efecto secundario de tener una herramienta de tamaño de diferencia disponible es que el código podría estar disponible como una opción para ejecutarse durante los impulsos para marcar confirmaciones legítimas que deberían haberse dividido en partes más pequeñas de todos modos. (Discusión relacionada sobre formas de hacer esto: https://github.com/go-gitea/gitea/issues/3658#issuecomment-372263759).

Apuesto a que hay muchas otras cosas sutiles que deberán abordarse para los servidores públicos. Podría tener sentido usar un hito o problema principal de "alojamiento público" separado para realizar un seguimiento de estas cosas.

Hablando de hitos, ¿debería agregarse este problema a 1.5.0?

@stevegt No, ya que creo que no todos los PR se fusionarán/resolverán en 1.5.0.

Eliminé Repository Size Limits (#3658) del problema ya que no afectará a Gitea alojado en Gitea.

Eliminé los límites de tamaño del repositorio (# 3658) del problema, ya que no afectará a Gitea alojado en Gitea.

¡Estupendo! Estoy seguro de que cuanto antes se aloje Gitea, más rápido todo el proyecto se beneficiará de las experiencias de la vida real y ganará confianza :)

@lafriks menciona en otro hilo:

El autohospedaje probablemente requiera financiamiento/patrocinio adicional para pagar una máquina virtual adicional

Y @lunny pregunta arriba:

@bkcsoft ¿Quiso decir que será un servicio público para alguien?

¿Sería factible combinar esos pensamientos en un "¿Qué tal si configuramos un servicio de Gitea en línea, donde la gente paga por (digamos) repositorios privados?".

Si se hace bien, eso debería generar los fondos para pagar por sí mismo + los repos públicos.

Como concepto, parece ser un terreno bastante transitado. :sonrisa:

Para agregar rápidamente a la idea de @justinclift ; el momento podría ser el adecuado con las noticias actuales de que Microsoft se hará cargo de GitHub.

@lafriks menciona en otro hilo:

El autohospedaje probablemente requiera financiamiento/patrocinio adicional para pagar una máquina virtual adicional

Confío en que habrá financiación de la comunidad o patrocinio de organizaciones para hacer posible el alojamiento de gitea. Dado que Gitea es amigable con los recursos (sí, GitLab, te estoy mirando), esto no será un gran problema.

@mxmehl hasta ahora ha habido 5 personas que han contribuido desde que opencollective abrió el mes pasado: https://opencollective.com/gitea

@justinclift como Gitea es puramente comunidad para impulsar, no hay forma de que podamos configurar repositorios privados pagados, ya que eso requiere crear una empresa, lidiar con los impuestos y tener personal a tiempo completo para lidiar con problemas técnicos

@mxmehl hasta ahora ha habido 5 personas que han contribuido desde que opencollective abrió el mes pasado: https://opencollective.com/gitea

@techknowlogick No conocía esta página. Ahora son 6 ;)

@lafriks Bueno .... hay proyectos comunitarios de todo - tanto de software y no de software - cosas que parecen administrarse a sí mismos bien, incluidas las cuestiones financieras, lo que pagan por, el personal (cuando sea necesario), y así sucesivamente.

Dicho esto, se requiere un nivel de voluntad para que suceda y siga adelante. Las personas en los roles necesarios también deben ser buenos custodios (confiables, confiables, con pistas).

Si no hay interés, entonces no irá a ninguna parte de todos modos. Lo mismo ocurre si no se pueden acordar tipos de "custodios" adecuados.

Desde el enlace de Open Collective mencionado anteriormente, parece que algunas semillas iniciales están en su lugar. Demuestra que hay personas alrededor que se consideran aceptables como custodios. :sonrisa:

@justinclift No digo que no sea posible, pero no en la etapa actual, pero podría suceder en el futuro. Actualmente, al menos, sería mejor que me centrara en desarrollar nuevas funciones de Gitea y mejorar la documentación :) Por lo tanto, cualquier ayuda es muy apreciada para avanzar más rápido hacia este objetivo.

je je je

No te preocupes en absoluto @lafriks. :sonrisa:

El primero de los objetivos es que Gitea aloje a Gitea desde que github se casó con Microsoft. :)

Creo que solo el n.º 2519 y el n.º 3748 deben revisarse y fusionarse antes de cerrar este problema.

@bkcsoft

Se agregaron "Límites de tamaño del repositorio" ya que no tenemos almacenamiento ilimitado en los servidores...

Mi propuesta de límites:

• 0 organizaciones
• 3 Repos
• 1GB/repositorio

Creo que, con el límite de cantidad de repositorios, podemos agregar permisos para establecer la bifurcación solo de los repositorios existentes para todos los usuarios que no están en el equipo de Gitea:

• 0 organizaciones
• 3 Repos (permitir solo horquillas)
• 1GB/repositorio

No creo que el recuento de bifurcaciones deba limitarse, de todos modos estaría limitado por el recuento del repositorio de gitea org, por lo que debería estar bien.
En cuanto al tamaño del repositorio, sí, probablemente debería haber algunos límites.

Deberíamos limitar la creación de organizaciones, la creación de repositorios, por lo que el límite de tamaño del repositorio no es un problema necesario para Gitea alojado en Gitea.

Podríamos considerar agregar #3134 y #4302 (PR y backlinks de emisión) a la lista de requisitos previos para el alojamiento propio; tal vez soy único, pero nuestra pequeña instalación de Gitea comenzó a ser difícil de manejar sin esos backlinks tan pronto como agregamos más de algunos usuarios y problemas. Hemos podido solucionar algunos problemas con la búsqueda de problemas, pero eso es limitado sin la búsqueda global de problemas (n.º 2434/n.º 3841).

@stevegt Si bien sería bueno tener vínculos de retroceso, no los veo bloqueando el cambio al alojamiento propio :)

@bkcsoft Bastante justo, solo pensé en mencionarlo en caso de que provocara alguna realización. En nuestro caso local, hemos desarrollado el hábito de agregar manualmente los vínculos de retroceso en los comentarios de problemas como solución alternativa.

Recientemente escuché sobre el esfuerzo de https://teahub.io. Quieren iniciar una organización sin fines de lucro. ¿Gitea no puede usar eso una vez que estén listos con la configuración?

@jlelse No. Gitea configurará un servidor independiente (es decir, self.gitea.io) para alojar gitea y duplicar a github, gitlab o teahub, etc.

@lunny ¿Realmente necesitamos comentarios sobre confirmaciones ya que actualmente solo usamos comentarios sobre relaciones públicas en GitHub?

@JonasFranzDEV Me refiero a comentarios sobre compromisos de relaciones públicas, creo que es necesario.

Estoy comentando aquí porque el #4108 está cerrado. Cuando sube Gitea Patreon (o una alternativa similar a Patreon), necesito saberlo. estaré contribuyendo. Me gustaría ver este proyecto autohospedado y desarrollado aún más. Una vez que mueva todos mis repositorios, ya no gastaré dinero con Github, lo comprometeré mensualmente con Patreon.

@ryanburnette https://opencollective.com/gitea

@lunny parece que se puede

@mjmlvp Creo que tienes razón. Eliminé #996 #2519 ya que no debería ser un bloque de este problema. Montaremos un servidor para alojar nuestros desarrollos.

Alguna noticia sobre esto ?

Sí, todavía tenemos que agregar limitaciones de aprobación y luego podemos migrar al código autoalojado.

Sería bueno agregar los problemas abiertos para eso a la lista. Por el momento, parece que todos los problemas vinculados y los RP se han cerrado y fusionado.

@skddc hecho.

para el registro

abrir servidores gitea

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

no confíes en nadie. hacer copias de seguridad periódicas

@giteauser no veo cómo eso es relevante

@giteauser y esto se trata del desarrollo de gitea con alojamiento propio, de modo que el desarrollo de gitea ya no tiene que ocurrir en github. Todavía no veo cómo esto es relevante.

Oh, publiqué esto por el problema equivocado, lo siento.

Por lo tanto, todas las características necesarias deben implementarse ahora. ¿Podemos tener una nueva versión y migrar?

Correcto, configuraremos una instancia de gitea para alojar el desarrollo de gitea.

Creo que solucionar el problema del volcado de la agregar la funcionalidad de restauración adecuada también es una parte importante para administrar la infraestructura de una gitea autohospedada.

Si está implementando Gitea en Kubernetes, puedo recomendar Ark para copias de seguridad y restauraciones.

En términos generales, la copia de seguridad no parece que deba ser un tema de bloqueo para el desarrollo de Gitea con alojamiento propio, porque cada uno suele tener diferentes estrategias/programas de copia de seguridad, según la plataforma que elija, el método de implementación, las herramientas existentes, etc. solo debería ser un problema de bloqueo para la preparación de producción de esa misma instancia.

@max-wittig El sitio web autohospedado de gitea se ejecutará en algún proveedor de nube pública. Proporcionarán el servicio RDS y la herramienta de copia de seguridad de la base de datos y alguna función de copia de seguridad del disco para que el comando de volcado de la copia de seguridad no sea un problema de dependencia. El comando de volcado es para un servicio gitea de un solo nodo. Por supuesto que deberíamos arreglar esos problemas.

@skddc Es una herramienta interesante que podemos considerar.

Realmente espero que la versión 1.8.0 sea la versión en la que gitea se autohospede. Personalmente, me encantaría usarlo para mis propios proyectos, pero solo estoy usando gitea como espejo por la sencilla razón de que no confío lo suficiente si los desarrolladores, ustedes, ni siquiera lo usan para el desarrollo de gitea. Además, me gustaría proponer el uso de gitea en mi entorno de trabajo, pero ni siquiera puedo proponerlo, ya que se reirán de mí cuando diga: "oh, por cierto, se ve increíble, pero los desarrolladores de gitea no usan para su propio proyecto"...

Esto no pretende ser una crítica o una forma de presionarlos amigos. Solo quiero hacerle saber lo que yo (y probablemente muchos otros) encontraría problemático cuando se trata de usar gitea como sistema principal de control de código fuente;)

Por último, para ser un poco más constructivo. Si está buscando un vps clous muy bueno (y barato) para copias de seguridad o incluso para alojar Gitea, eche un vistazo a Hetzner https://www.hetzner.com/storage/storage-box Aunque para una infraestructura importante como Gitea probablemente querrá hacer una copia de seguridad en dos ubicaciones completamente diferentes (por ejemplo, hetzner y digitalocean).

@markg85 estamos trabajando en https://gitea.com

¿Alguna actualización sobre gitea alojada en gitea en gitea.com?

@zachdoty Todavía están trabajando en eso.

Olvidé algo necesario para pasar de github a gitea. Necesitamos mover todos los datos (incluidos los datos de git, los problemas, los comentarios, las solicitudes de extracción de github a gitea), pero de hecho no he encontrado las herramientas adecuadas para hacerlo. He enviado relaciones públicas sobre cómo mover el repositorio de migración del frontend al backend, ver #6200, y también https://gitea.com/gitea/migrator debe fusionarse con gitea porque la API de gitea no permitirá crear un problema con un número de índice específico.

gitea-github-migrator puede migrar casi todo, en caso de que aún no lo hayas encontrado. Si falta algo, tal vez se pueda agregar allí, para que otros proyectos también tengan una buena herramienta para migrar.

@skddc en realidad son lo mismo.

Oh, lo siento. No había seguido el enlace.

Como dijo @kolaente , invitamos a @jonasfranz a mover gitea-github-migrator a gitea.com y le envío un PR https://gitea.com/gitea/migrator/pulls/1 quiere mejorar eso. Pero descubrí que, como herramienta de terceros, hay una desventaja. Es decir, es difícil mantener el índice de emisión como antes. (Para dejar que todos los enlaces sobre el problema sigan disponibles). Así que creo que fusionar la herramienta de migración en gitea en la interfaz de usuario de migración es una mejor idea.

Definitivamente sería increíble si los enlaces internos en los comentarios, etc. pudieran conservarse. ¡También sería increíble si los PR que se originan en el mismo repositorio pudieran importarse como PR reales en lugar de problemas!

Agregué una nueva tarea Migrate a throughout github repository to gitea en el contenido del problema y lo moví a 1.9.0 para que no bloquee el lanzamiento de v1.8. Pero no creo que debamos esperar hasta el lanzamiento de v1.9 ya que gitea.com seguirá al maestro.

¿Está lista la producción de Gitea.com? ¿Debería preocuparme por almacenar el código allí y perderlo?

@BNolet hemos configurado un clúster ceph de 6 máquinas para almacenar los repositorios. Por lo tanto, no debe perderse fácilmente ya que todos los datos se copiarán 3 veces. Estamos trabajando para configurar otra copia de seguridad a través de ceph mirror. Y dado que git se distribuye. Sus códigos siempre se almacenarán en su disco o en el de sus colegas.

¡Eso es fantástico! ¿Todos anticipan poder ser una alternativa completa a GitHub o Gitlab?

No lo creo. El objetivo principal de gitea.com es alojar los desarrollos propios de gitea. Aunque no hemos hecho ninguna limitación en gitea.com, lo alentamos a que configure usted mismo una instancia alojada de Gitea, ya que es muy fácil.

¿Algún motivo para no habilitar el inicio de sesión con OpenID?

@lunny tengo uno y me encanta :D

¿Qué probabilidad hay de que CI/CD se convierta en parte del producto Gitea?

@strk solo olvídalo. Habilitará el inicio de sesión de OpenID.
@BNolet Gitea usará drones como CI/CD principal.

Obtuve un error 500 al intentar usar la opción de autenticación de Github en la página de inicio de sesión, después de ir a la solicitud de permisos para la aplicación go-gitea en Github.

¿Debería esperar un poco para ver la instancia insignia?

@jakimphett ese es un problema conocido. Puedes intentarlo dos veces y está bien.

@strk solo olvídalo. Habilitará el inicio de sesión de OpenID.

@lunny como todavía estaba apagado hoy, ¿hay tal vez un script de implementación que lo sigue apagando?

@jakimphett ese es un problema conocido...

Agregue una edición con el número de problema y haré un seguimiento allí.

_editar(s): formato_

Codeberg es un servicio gratuito basado en Gitea. Quizás Gitea pueda instalar allí un espejo oficial. Actualmente está reflejado en https://codeberg.org/Codeberg/gitea.

Gitea se alojará en https://gitea.com/gitea/gitea , y hemos movido la mayoría de los otros paquetes a https://gitea.com/gitea , y gitea en sí está en progreso. Mirror es bienvenido en cualquier otro servicio basado en gitea.

@lunny comentó ayer:
Mirror es bienvenido en cualquier otro servicio basado en gitea.

Haré un espejo actualizado una vez que regrese de mi fin de semana.

Relacionado:
¿Hay una lista de espejos en alguna parte, y me agrego a ella, o...?

@jakimfett No lo hay, pero podría crear un pr con una nueva página de documentos

Para un mejor controlador de usuarios al migrar gitea fuera de github, me gustaría mover esto a v1.10 y creo que deberíamos implementar https://github.com/go-gitea/gitea/issues/7293 antes de comenzar a migrar.

Estaría totalmente a favor de ese movimiento si no estuviera alojado en China o el correo electrónico de activación tardara 10 minutos en llegar.

Estaría totalmente a favor de ese movimiento si no estuviera alojado en China o el correo electrónico de activación tardara 10 minutos en llegar.

Editar: aparentemente, estaba equivocado.

de algunas búsquedas en Google, aparentemente la dirección IP de gitea.com está en realidad en Japón, no en China. Sin embargo, esa dirección IP es propiedad de Alibaba.

Usamos mailgun.org para enviar correos. No sé por qué tardará 10 minutos.

Nuestro proveedor de nube de donaciones es didiyun, que está en China y proporciona muchas máquinas. No tenemos otra opción actualmente.

Y el primer propósito de gitea.com no será un servicio como github.com o gitlab.com. Solo alojará gitea en sí y le recomendamos que configure usted mismo la instancia de gitea.

@programmerjake Ese es un servidor puente.

No era mi intención cambiar mi instancia, pero no me gusta que este proyecto dependa de una infraestructura donada por una empresa china que casi no tiene reputación en el pasado ni resultados de búsqueda. Realmente no sabes lo que harán en el futuro o si exigen reducir su donación si no implementas XY o haces ZA o si simplemente se van algún día.
Probablemente sepa lo que está haciendo y mis preocupaciones son demasiado cautelosas, pero nunca lo sabrá.

¿Por qué una empresa china hará eso pero una estadounidense no? :)

Y yo soy chino, y tal vez deberías tener cuidado. Algún día puede que robe tus códigos. :)

Creo que puedo tener ese plan cuando comencé Gogs con otros 3 chinos en 2014.

No era mi intención cambiar mi instancia, pero no me gusta que este proyecto dependa de una infraestructura donada por una empresa china. Realmente no sabes lo que harán en el futuro o si exigen reducir su donación si no implementas XY o haces ZA o si simplemente se van algún día.
Probablemente sepa lo que está haciendo y mis preocupaciones son demasiado cautelosas, pero nunca lo sabrá.

Esa es una respuesta totalmente idiota.
Ahora podría tener una mente más abierta ya que soy holandés, lo aceptamos un poco. Tu también deberías intentarlo.

Mientras este proyecto sea de código abierto, en mi opinión, no hay riesgo por nada de lo que dijo.
E incluso si lo hacen, lo que probablemente signifique bifurcar a Gitea, tienen todo el derecho ya que la licencia simplemente lo permite.

Sin embargo, EE. UU.... Permítanme recordarles que Github ha limitado sus funciones ahora debido a la "guerra comercial" entre EE. UU. y China. En todo caso, EE. UU. es más un riesgo para el desarrollo de software libre en este momento que China nunca lo ha sido. Diablos, @lunny probablemente incluso se

@lunny y el equipo que desarrolla Gitea. Sigan con el trabajo impresionante! :)

Y el primer propósito de gitea.com no será un servicio como github.com o gitlab.com. Solo alojará gitea en sí y le recomendamos que configure usted mismo la instancia de gitea.

¿Es algo que usted puede considerar en el futuro?

Mientras este proyecto sea de código abierto, en mi opinión, no hay riesgo por nada de lo que dijo.

El proyecto central no tiene riesgo, pero la infraestructura sí. No hay garantías de que el donante desconocido y de mala reputación estará allí el próximo mes, sin importar si viene de cualquier parte o de China. GitHub estará aquí por mucho tiempo y no irá a ningún lado tan rápido.

Además, si toda la infraestructura se traslada a China, toda la base de usuarios sufrirá debido a las dificultades entre EE. UU. y China.

@lunny Con respecto a los correos electrónicos que
Obviamente, tenemos algunas "fuentes confiables" configuradas, como GMail, Hotmail, etc. que no necesitan un período de reflexión.

Gente, si desea más infraestructura distribuida para cada región, vote con su billetera en https://opencollective.com/gitea

@SuperSandro2000 ¿Eres consciente de que Gitea no es un servicio sino un _producto_? Descargas las fuentes, compilas Gitea en tus servidores y lo instalas. No se requiere conexión alguna al hosting de Gitea.

si exigen cortar su donación si no implementas XY o ZA o si simplemente se van algún día.

No hay garantías de que el donante desconocido y de mala reputación estará allí el próximo mes.

Un par de respuestas a esto: no hospedaríamos en una empresa de mala reputación, y los líderes de Gitea han depositado nuestra confianza en esta empresa. Si dejan de proporcionar patrocinio o dejan de ser una empresa, tenemos opciones disponibles y podemos mudarnos a otro lugar.

toda la base de usuarios sufrirá debido a las dificultades entre EE. UU. y China.

Una gran parte del equipo de Gitea es de China (pero también tenemos mantenedores en todos los demás continentes), y si el equipo de desarrollo no puede acceder al código, la base de usuarios se verá afectada, por lo que necesitamos que el equipo de desarrollo pueda acceder código. Creamos Gitea para que todos puedan usarlo, incluso los usuarios que están prohibidos en GitHub (después de la reciente ola de prohibición de GitHub, muchos de esos usuarios comenzaron a usar Gitea).

Como han mencionado otros, hay espejos de la base de código en otras instancias de todo el mundo y, gracias a git, hay un registro de todos los cambios realizados en el código para que todos puedan ver todos los cambios.

Una nota sobre la transparencia: he bloqueado este hilo. No quiero detener esta conversación, sin embargo, debe moverse a un lugar diferente ya que este ticket de github trata sobre las mejoras que se deben hacer con el software para el alojamiento propio (en lugar de donde estamos alojando).