Καλημέρα! (Good morning!) This time we greet you from the Greek city of Heraklion.
From the very beginning of work on GitLab, we have been striving to create a tool that allows everyone to contribute . With each release, we are one step closer to this goal. In GitLab 10.1, new collaboration tools have appeared, security has improved, the authentication mechanism has improved, productivity has grown, and the interface has become even more convenient.
When you discuss the code, it is very convenient to comment on specific lines. What about images? Often, the application has a user (or web) interface, or other graphics - and to work on them you need a tool similar to commenting lines. GitLab now has such a tool, it is called image discussions. Also in GitLab you can now open merge requests between the forks of one repository .
We are constantly improving security and working on authentication mechanisms. In this release, we added filters to synchronize LDAP groups and the ability to reject unsigned commits . We also added new metrics to the audit log for administrators and implemented GPG plug-in support .
Open source projects attract many visitors and contributors. These people do not always communicate in a civilized manner. GitLab 10.1 has a moderation tool: you can now block discussion of tasks and Merge Requests .
We follow our vision for DevOps . In this release, we have simplified the creation of Google Container Engine clusters from GitLab . HTML build artifacts now open directly in the GitLab interface. This allows you to view test results without having to publish them somewhere.
The option “fast-forward merge” , previously available only in Enterprise Edition Starter, will now appear in Community Edition.
We have updated the project creation page : now it’s easier to select the type of project you need. You can create an empty project, use a template, or import a project from an external repository.
As always, we are working on the performance of GitLab. This release includes many improvements , including speeding up downloads of merge requests and other pages.
The title of MVP this month was Vitaliy Klachkov (blackst0ne habrauser ), who proposed as many as 23 improvements . He has been involved in the development of the GitLab for quite some time and is a member of the GitLab core team . Vitaly worked on various tasks: from the API and user interface to test development (18 Merge Requests!) And rightfully earned the title of MVP.
Vitali, thank you for your work!
Everyone can make a contribution to GitLab, but not every contribution was convenient to discuss. Now, the work of graphic designers, interface designers, illustrators, front-end developers and everyone else who works with images can be commented on in detail.
To start a discussion, click anywhere in the image on the commit or merge-request page. On one image there can be several points of discussion.
When the discussion has ended, mark it as completed - just like in the discussion of the code. The counter of open discussions in a merge request takes into account both types of discussions.
Documentation for commenting on images .
In this release, it is possible to block the discussion in a specific task or merge-request. After that, only members of the project will be able to edit or send new messages. The lock is available to accounts with an access level to this project not lower than Master. Blocking can be useful in combating spam or misbehavior, as well as to transfer the discussion to another task or request.
Documentation on blocking discussions .
A fork is an independent copy of the repository that any developer can create. Forks and Merge Requests offer a good alternative to working with branches within the same repository: they allow developers to propose changes without having direct access to push to the main repository.
Previously, forks were isolated from each other. Developers working in different forks could not offer a merge-request to each other. In GitLab 10.1 this has become possible.
Collaboration in forks has become easier. Now developers can open merge requests, make reviews and put changes together before sending merge requests to the main repository.
Documentation on merge requests between forks of one repository .
We continue to work on extending Enterprise authentication capabilities: GitLab 10.1 introduced the ability to synchronize with filter-based LDAP groups, including custom attributes .
Large and complex LDAP implementations may contain additional metadata for access permissions, roles, and user types. The introduction of group filters extends user control directly through LDAP.
GitLab EES already supports synchronization of LDAP and GitLab groups at a basic level. However, with this approach, the structure of the LDAP and GitLab groups should be identical.
Introducing group synchronization filters to GitLab EEP extends the use of existing LDAP structures and attributes, which allows you to more effectively manage access in GitLab.
Documentation for group LDAP synchronization filters .
The ability to authenticate the author of a commit through GPG integration was added to GitLab 9.5 . And now in GitLab Enterprise Edition Premium there is an opportunity to use push rules to test and reject unsigned commits.
Documentation for rejecting unsigned commits .
Any application needs a home, and in the case of web applications and microservices, this home can be a cluster of Kubernetes , which is also able to deploy applications for review in the development cycle. However, it is worth remembering that setting up a cluster is not an easy job, and developers should not be distracted from writing code to set up an infrastructure.
Therefore, we have added to GitLab 10.1 the possibility of linking a Google account to projects, as well as creating new Kubernetes clusters on the Google Container Engine (GKE) . To do this, it is enough just to enable the corresponding services for your account and set several parameters. Such clusters are ready for use immediately after creation and can be used, for example, Auto DevOps to run your applications.
Documentation on how to simplify the creation of Kubernetes clusters on GKE (beta) .
Many projects rely on automated GitLab testing, so developers should have access to test results. This is just one of the examples that demonstrate the importance of creating HTML reports and providing easy access to them.
In GitLab 10.1, we added online rendering of HTML files created by public project pipelines. It is located in one click from the artifact viewing window. Now you can easily view your test reports, code quality, and coverage information right in your browser, without downloading.
Documentation on the online display of HTML artifacts .
In GitLab 9.5 , integration with GPG was added , thanks to which it became possible to sign commits for authentication. The use of confirmed subkeys for signing commits is widespread, so this feature was added in GitLab 10.1.
Documentation on the signing of commits subkeys GPG .
Creating a project is the first step when working with GitLab. In this release, we improved the New Project creation page ( New Project ) to simplify this process. It is now easier to apply project templates added in GitLab 9.5 , so you can create empty projects, projects with working code examples and a pre-configured CI, and also import existing projects from another location.
Documentation on improvements to the new project creation page .
We have added additional credentials to developers, since managing the Mylston towns is the responsibility of the software development team. Users with developer rights can now create, edit, and delete milestones of projects and groups.
Milestone management documentation with developer access level .
We are continuing to work on the localization of GitLab. In this release, we externalized (externalize) the lines on the Branches, Group and Wiki pages, which will allow our community to add more languages and lines to GitLab.
If you want to participate in the localization of GitLab, we will be glad to see you in our localization community .
Documentation on localization improvements .
For security audits, it is extremely important to be aware of everything that happens in your GitLab instance.
The GitLab EES (Enterprise Edition Starter) contains basic event revision capabilities: a simple log of past events is maintained for each group and repository.
The user action log was added to GitLab 9.3 , giving administrators access to the centralized event log of groups, projects, and individual user actions. New actions have been added to GitLab 10.1 logs:
Documentation on improvements to user activity logs .
Many GitLab users have told us that, even when working in small teams, they lack the flexibility to choose the merge method. In this release, we add semi-linear history functionality to GitLab Community Edition (CE ).
and merge-requests fast-forward , previously available only in GitLab Enterprise Edition.
Documentation on semilinear history and fast-forward merge in CE .
Prior to GitLab 10.1, notifications in Slack included only the username of the user GitLab. In this release, you will be able to see the full name of the user. In the new format, the reference looks like this: ()
.
GitLab username documentation in Slack notifications .
From now on, you can use the new implements
keyword and its variations in the commit message or merge-request description. When the merge-request is accepted and the commit falls into a stable branch, the task will be automatically closed (marked as completed):
git commit -m 'Do foo; fix bar; implements #123'
A new keyword is added to the already known closes
, fixes
and resolves
and their variations.
Keyword documentation for automatic closing of tasks .
To enhance security, GitLab now requests confirmation of email at registration.
This functionality now extends to additional email addresses that the user has added to the account to ensure that all email addresses are verified.
Email Reconfirmation Documentation
gitlab.rb
: effective_io_concurrency
, max_worker_processes
, max_parallel_workers_per_gather
, log_lock_waits
, track_io_timing
and deadlock_timeout
.Documentation on Omnibus improvements .
Important changes released with GitLab 10.1:
See the full list of changes .
Performance is an important part of GitLab, allowing it to scale to support hundreds or even thousands of users.
GitLab 10.1 includes 20 performance improvements, including faster viewing of Merge Requests, accelerated GitHub imports, and general home page load improvements. Section Container Registry is now divided into several pages, which greatly simplified working with him. Optimized the search process from the toolbar - it now has a view of projects and tasks. Rebase button has become much faster.
All performance improvements here .
Also with this release we release GitLab Runner 10.1! GitLab Runner is an open source project used to run your CI / CD works and send the results back to GitLab.
A complete list of changes can be found in CHANGELOG for GitLab Runner .
GitLab Runner Documentation 10.1 .
Detailed release notes and instructions for updating / installing can be found in the original English post: GitLab 10.1 Released with Unsigned Commits .
Translation from English is made by translational artel "Nadmozg and partners", http://nadmosq.ru . Rishavant , sgnl_05 and nick_volynkin worked on the translation.
Source: https://habr.com/ru/post/341458/
All Articles