El proyecto CentOS pasa al desarrollo usando GitLab

El proyecto CentOS anunció el lanzamiento de un servicio de desarrollo colaborativo basado en la plataforma GitLab. La decisión de utilizar GitLab como plataforma de alojamiento principal para proyectos CentOS y Fedora se tomó el año pasado. Cabe destacar que la infraestructura no se construyó sobre sus propios servidores, sino sobre la base del servicio gitlab.com, que proporciona una sección gitlab.com/CentOS para proyectos relacionados con CentOS.

Actualmente, se está trabajando para integrar la sección con la base de usuarios del proyecto CentOS, lo que permitirá a los desarrolladores conectarse al servicio Gitlab utilizando cuentas existentes. Cabe señalar por separado que git.centos.org, basado en la plataforma Pagure, seguirá siendo considerado como un lugar para alojar el código fuente de los paquetes transferidos desde RHEL, así como como la base para la formación de CentOS Stream 8. rama Pero la rama CentOS Stream 9 ya se está desarrollando en base al nuevo repositorio en GitLab y se distingue por la capacidad de conectar a los miembros de la comunidad con el desarrollo. Otros proyectos alojados en git.centos.org permanecen vigentes por ahora y no están obligados a migrar.

Durante la discusión de la decisión, los opositores a la transición al modelo SaaS señalaron que el uso de un servicio listo para usar proporcionado por GitLab no permite un control completo de la infraestructura, por ejemplo, es imposible estar seguro de que la infraestructura del servidor se mantiene adecuadamente, las vulnerabilidades se eliminan rápidamente y la telemetría y el entorno no se verán comprometidos como resultado de un ataque externo o las acciones de empleados deshonestos.

Al elegir una plataforma, además de las operaciones estándar con repositorios (fusionar, crear bifurcaciones, agregar código, etc.), existían requisitos como la capacidad de enviar solicitudes push a través de HTTPS, medios para restringir el acceso a sucursales, soporte para sucursales privadas. , separación del acceso a usuarios externos e internos (por ejemplo, para trabajar en la eliminación de vulnerabilidades durante un embargo sobre la divulgación de información sobre el problema), familiaridad con la interfaz, unificación de subsistemas para trabajar con informes de problemas, código, documentación y planificación de nuevos características, disponibilidad de herramientas para la integración con IDE, soporte para flujos de trabajo estándar, la capacidad de usar un bot para fusiones automáticas (requiere CentOS Stream para admitir paquetes del kernel).

Fuente: opennet.ru

Añadir un comentario