Projects and on the decision to create a collaborative development service, Git Forge, which will be built using the GitLab platform. GitLab will serve as the primary platform for interacting with Git repositories and for hosting projects related to CentOS and Fedora distributions. The previously used service will continue to exist but will be handed over to the community interested in continuing development. Pagure will be removed from the support of the staff team at Red Hat CPE (Community Platform Engineering), which is responsible for maintaining the infrastructure for developing and publishing Fedora and CentOS releases.
When evaluating possible solutions for the new Git Forge,
Pagure and GitLab were considered. Based on the study of about and requests from participants in the Fedora, CentOS, RHEL, and CPE projects, requirements for functionality were formed, and a decision was made in favor of GitLab. In addition to standard repository operations (merging, forking, adding code, etc.), key requirements included security, ease of use, and platform stability.
Requirements included capabilities such as sending push requests over HTTPS, branch access control tools, support for private branches, separation of access for external and internal users (for example, to work on vulnerability fixes during an embargo on disclosing information about the issue), familiarity of the interface, unification of subsystems for issue tracking, code, documentation, and planning new features, availability of tools for integration with IDEs, and support for standard workflows.
Among the features of GitLab that ultimately influenced the decision to choose this platform are support for subgroups with selective repository access, the ability to use a bot for automatic merges (requires CentOS Stream for maintaining packages with the kernel), the availability of built-in tools for development planning, and the option to use an existing SAAS service with guaranteed availability (which will free up resources for maintaining server infrastructure).
The decision has already been criticism among developers regarding the decision being made without prior extensive discussion. Concerns were also raised that the service would not use the free Community edition of GitLab. In particular, the features necessary to fulfill the requirements outlined in the Git Forge announcement are only available in the proprietary version. .
The plan to utilize the SAAS (Software as a Service) offered by GitLab was also criticized, as it moves the service out of control (for example, it becomes uncertain whether all vulnerabilities in the system are addressed promptly. maintained infrastructure will not suddenly cease and the risk of sabotage by third-party personnel will be eliminated). The decision also does not align with , which state that the project should prioritize free alternatives.
Meanwhile, GitLab announced the introduction of 18 functionalities that were previously only offered in proprietary editions of GitLab. These functionalities span various areas of software development lifecycle management, including development planning, project creation, verification, package management, release generation, and configuration and protection.
The following features have been made free:
- Linking related issues;
- Exporting issues from GitLab to CSV;
- Planning, organizing, and visualizing the development process of individual features or releases;
- An integrated service for connecting project participants with third parties via email.
- Web terminal for Web IDE;
- File synchronization opportunities for testing code changes in the web terminal;
- Design management tools that allow uploading mockups and resources to issues, using issues as a single access point for everything needed to develop a new feature;
- Code quality reports;
- Support for package managers Conan (C/C++), Maven (Java), NPM (node.js), and NuGet (.NET);
- Support for canary deployments, allowing the new version of an application to be deployed on a small subset of systems.
- Incremental releases that allow the initial delivery of new versions to a small number of systems, gradually increasing coverage to 100%;
- Feature activation flags that enable the project to be delivered in various editions, dynamically activating certain features;
- Deployment overview mode that allows assessment of the status of each continuous integration environment based on Kubernetes;
- Support for defining multiple Kubernetes clusters in the configurator (for example, separate Kubernetes clusters can be used for trial deployments and production workloads);
- Support for defining container network security policies that restrict access between Kubernetes pods.
Additionally, it can be noted updates GitLab 12.9.1, 12.8.8, and 12.7.8 (Community Edition and Enterprise Edition) that fix a vulnerability. The issue manifests from the GitLab EE/CE release 8.5 and allows reading the contents of any local file when moving issues between projects.
Details about the vulnerability will be disclosed in 30 days.
Source: opennet.ru
