Projects ΠΈ about the decision to create a Git Forge collaborative development service, which will be built using the GitLab platform. GitLab will be the primary platform for interacting with Git repositories and for hosting projects related to CentOS and Fedora distributions. Previously used service will continue to exist, but will be left in the care of the community interested in continuing development. Pagure will be removed from the support of the CPE (Community Platform Engineering) team employed at Red Hat, which maintains the infrastructure for developing and publishing releases of Fedora and CentOS.
When evaluating possible solutions for the new Git Forge, we considered
pagure and gitlab. Based on a study of about and wishes from the participants of the Fedora, CentOS, RHEL and CPE projects, requirements for functionality were formed and a choice was made in favor of Gitlab. In addition to typical operations with repositories (merging, creating forks, adding code, etc.), security, usability and stability of the platform were declared among the key requirements.
The requirements included features such as sending push requests over HTTPS, means to restrict access to branches, support for private branches, separation of access between external and internal users (for example, to work on fixing vulnerabilities during a disclosure embargo), familiarity interface, unification of subsystems for working with problem reports, code, documentation and planning for new features, the availability of tools for integration with the IDE, support for standard workflows.
Of the features of GitLab, which finally influenced the decision to choose this platform, they mentioned support for subgroups with selective access to repositories, the ability to use a bot for automatic merges (CentOS Stream is required to maintain packages with the kernel), the presence of built-in tools for planning development, the ability to use a ready-made SAAS service with a guaranteed level of availability (will free up resources to maintain the server infrastructure).
The solution is already criticism among developers related to the fact that the decision was made without prior wide discussion. Concerns were also raised that the service would not use the free Comminity edition of GitLab. In particular, the features necessary to implement the requirements for Git Forge described in the announcement are available only in the proprietary version. .
The intention to use the SAAS (application as a service) service provided by GitLab, instead of deploying GitLab on their servers, was also criticized, which takes the service out of control (for example, it is impossible to be sure that all vulnerabilities in the system are promptly fixed, infrastructure is maintained, one fine moment will not be and sabotage by the personnel of a third-party company is excluded). The solution is also incompatible with , which specify that the project should give preference to free alternatives.
Meanwhile, GitLab about opening implementations of 18 features previously offered only in proprietary editions of GitLab. Capabilities cover various areas of software development life cycle management, including development planning, project creation, verification, package management, release generation, customization and protection.
The following functions have been transferred to the number of free ones:
- Attaching related issue;
- Export issue from GitLab to CSV;
- The mode of planning, ordering and visualization of the development process of individual features or releases;
- Built-in service service for connecting project participants with third parties using email.
- Web terminal for Web IDE;
- The ability to synchronize files to test changes in the code in the web terminal;
- Design controls that allow layouts and resources to be loaded into an issue, using the issue as a single point of access to everything needed to develop a new feature;
- Code quality reports;
- Support for Conan (C/C++), Maven (Java), NPM (node.js) and NuGet (.NET) package managers;
- Support for canary deployments that allow you to install a new version of the application on a small part of the systems;
- Incremental distributions, allowing new versions to be delivered initially to only a small number of systems, gradually bringing coverage up to 100%;
- Functionality activation flags, which make it possible to deliver the project in various editions, dynamically activating certain features;
- Deployment overview mode, which allows you to assess the status of each Kubernetes-based continuous integration environment;
- Support for defining multiple Kubernetes clusters in the configurator (for example, you can use separate Kubernetes clusters for trial deployments and workloads);
- Support for defining container network security policies that allow you to restrict access between Kubernetes pods.
Additionally, it can be noted GitLab 12.9.1, 12.8.8 and 12.7.8 (Community Edition and Enterprise Edition) updates fixing the vulnerability. The issue has been manifest since the release of GitLab EE/CE 8.5 and allows you to read the contents of any local file when moving an issue between projects.
Details about the vulnerability will be disclosed in 30 days.
Source: opennet.ru