In GitLab 9.3, we present Code Quality, pipeline design inter-schedules, collaborative development index, localization improvements, snippets descriptions, and more!
GitLab is an integrated product for the entire development cycle. With the release of each monthly release, we strive to add new aspects of co-writing code, continuous integration, release automation and monitoring. So, in GitLab 9.3, we introduced functionality that allows us to improve the quality of the code, reduce the development cycle time, and simplify the management of large projects.
In GitLab 9.3, Code Quality reports have been added, which are displayed directly in the Merge Request widget. These reports allow you to instantly assess the impact of the proposed changes on the status of your code and the project as a whole. Due to this, the time for the review is reduced, and it also becomes possible to find mistakes before merge.
Modern production-level software, especially the one that uses micro-services architecture, often consists of many different projects. In such software it is very important to understand the interaction of projects. In GitLab 9.3, you can see the relationship between upstream and downstream pipelines using inter-project pipelines .
GitLab 9.3 also provides an opportunity to evaluate how you use each element of GitLab in comparison with other people. For this, a joint development index is used. Using this index, you can easily assess how efficiently you use the system compared to other users, and also see which elements of your workflow you could improve.
We created a small video that allows you to evaluate the capabilities of GitLab and its new functionality, as well as ensure that GitLab allows you to fit the entire development process on a single platform.
Huang has made a significant contribution to the localization of GitLab to several new languages. Thank you, Huang!
It is difficult to overestimate the importance of the correct code review. When reviewing the changes made, it is important to pay attention to the quality of the code, implementation, formatting, and more. Even if the review is carried out qualitatively, it is impossible to achieve consistency in this process without any assessment of the quality of the code.
We created GitLab Code Quality in order to speed up the code review process and allow users to make a comparative assessment of the quality of the code and create the corresponding reports right in the merge request window. Now, if the quality of your code deteriorates, GitLab will point you to this, and you can rectify the situation before merge.
More information about GitLab Code Quality in our documentation.
In large projects, especially those using a micro-services architecture , the final product often consists of a set of interdependent components. Because of this, at times it is not easy to understand why a certain pipeline was launched or why one project was built after a commit in another.
In GItLab 9.3, you can now display connections for upstream and downstream projects directly on pipeline graphs, making it easy to see the status of the entire chain in one window. Now, to display links between projects, you do not need to use the $CI_JOB_TOKEN
variable with triggers - charts are created automatically.
More information about inter-project pipeline schedules in our documentation.
Last September, we announced the principles of joint development (Conversational Development - ConvDev) . The introduction of this methodology speeds up the process of software development from idea to implementation.
GitLab 9.3 includes a collaborative development index, which provides a numerical display of the use of this methodology. With this index, you can evaluate your performance compared to other GitLab users, as well as see elements of your workflow that you could improve.
In this version, this index is available only to system administrators. The index is based on the activities of all active users of your GitLab instance.
More information on the collaborative development index in our documentation.
Secret variables are useful in cases where certain information needs to be hidden from external users, but it is open to users with access to make changes to the project. With this approach, situations are possible when those users who, ideally, should not do this, make changes to the development environment; they may not even have write access to the master
.
In GitLab 9.3, with the introduction of protected variables, there is an additional level of security for secret information, such as deployment authority. Now in Settings
-> CI/CD Pipelines
you can mark the variable as “protected”. Such a variable will be available only for tasks performed on protected branches, so that access to it will be open only to users with the appropriate access rights.
More information on protected secret variables in our documentation.
Many companies need to report changes in access rights during the entire development cycle. In GitLab 9.3, each system administrator has access to an improved centralized log of user actions, which contains all the relevant events of groups, projects, and actions of individual users.
In addition, in this log, you can filter events by type and name, so you can easily find the events of certain groups, projects or users.
More information about audit logs in our documentation.
Over time, we added a lot of new functionality and configuration options for projects and groups, and, as a result, the number of GitLab settings has increased significantly.
In GitLab 9.3, we begin work on simplifying setup pages . The first step was to improve the readability of the repository settings page .
We strive to improve the grouping of settings and add an overview of all the settings for each section.
In this release, we improved the JIRA integration settings, which makes it easier to set up and test the connection between the GitLab project and the JIRA server. Also added are separate Web URL and JIRA API URL fields. This separation is useful in cases where the JIRA REST API and JIRA tasks are located at different addresses.
More information on JIRA integration in our documentation.
Users with the rights Reporter, Developer, Master and Owner in addition to project shortcuts can now create and edit group shortcuts. Previously, only Master and Owner could do this.
More information about the GitLab permissions model in our documentation.
Task description is the reference point and the main source of information when several teams work together. In GitLab 9.3, we removed the transition to a separate page when editing the task description. Just click Edit
, make changes and click Save changes
- all this time you stay on the task page. Since redirection to another page is now absent, during editing you can scroll through comments on the task and even copy and paste the text GFM into the description
More information about the tasks of GitLab in our documentation.
We understand that different teams have their own approaches to using task boards. To simplify interaction with them, we added the ability to collapse the Backlog and Closed columns. We also made changes to the process of adding new tasks to the board: when you click on +
task is automatically added to the top of the list, which seriously simplifies working with long lists.
More information on GitLab task boards in our documentation.
In GitLab 9.2, we started the localization process by translating the analytics page of the development cycle into German and Spanish. In GitLab 9.3, we translated the most frequently used pages: the project home page and the repository files page.
The GitLab community has already started adding other languages ​​- Chinese, Bulgarian, and Brazilian Portuguese. You can watch the changes and take a look at their guidelines if you want to connect.
Learn how GitLab translation community interaction is built.
When you deploy a Docker-based project, you need to pull up the image every time your environment needs to run it. Since the built-in registry of GitLab containers is the obvious choice for storing your containers, in GitLab 9.3 you can also use it for distribution.
Create a personal access token with the new read_registry
area, and you will have a permanent deployment token that external services like Kubernetes can use to access your images if necessary - without entering all your data or using a dummy user for this task.
For more information, see the documentation on tokens for personal access.
During the review of the merge request code, we constantly change the code and comment on these changes. Often it is difficult to track. In particular, when we begin to comment on a specific line of code, and someone else simultaneously makes changes there. It may end up discussing something that you have already changed.
In this release, we added a system note - an indicator that the line has already changed. If you participate in the discussion of a particular line, you will find out that it has already been changed, and you can see the changes by clicking on it.
To get the most out of the automatic cancellation of unnecessary pipelines and save many hours of development, GitLab 9.3 extends this behavior to all existing and new projects.
If you do not need to cancel unnecessary pipelines, you can adjust the corresponding parameters to suit your needs.
As part of the upcoming release of GitLab 9.4, we will update the version of nginx included in Omnibus to the new stable version 1.12. This version includes several improvements to the previous stable version. For example, it is possible to filter log output .
For users, this update should be understandable, but if you changed the settings in the nginx configuration, please, after upgrading to 1.12, make sure that they work correctly.
Support for the latest release of Debian 9 is available . You can download the official Omnibus packages for GitLab 9.3 from the installation section .
GitLab 9.3 includes the Mattermost 3.10 , an open source alternative to Slack . This version introduces Turkish language support, new hotkeys, and more.
Read more about the GitLab Mattermost changes in the documentation.
The associated Git and PostgreSQL packages have been updated. Git has been updated to version 2.13.0, and Postgres to 9.6.3.
Snippets now have descriptions. This applies only to personal snippets that we added in the previous release . Snippets are a powerful tool for quick and easy collaboration on code. In this release, working together on them has become as easy as it is on merge-requests.
We continue to improve GitLab performance with every release. This will not only make each GitLab instance even faster, but also increase the instance's performance with a million users - GitLab.com.
In GitLab 9.3, we continue to accelerate the display of a list of projects, and also generally improve server performance by changing how we mirror repositories. Syntax highlighting of files is now cached, it improves overall performance and speeds up the display of commits.
There are many other performance improvements in GitLab 9.3 that not only make GitLab faster, but also reduce the impact on the server infrastructure as a whole.
We have made mass editing of tasks easier and more understandable than in the last release. Now when updating several tasks at the same time, the same sidebar is used as in many other elements of GitLab.
Read more in our task documentation in GitLab.
We continue to gradually improve search and filtering. Now you can see custom avatars.
Also, clicking on the filter causes a drop-down menu that allows you to quickly change filters.
Details can be found in the search documentation for GitLab.
In GitLab 9.0, we added subgroups , making group and project management more flexible. With each release, we continue to improve this functionality: this time we have made more intuitive navigation through subgroups. On the groups page, you can see an expandable tree with all projects and subgroups - instead of searching and loading one page at a time.
When viewing files in the repository, additional information is now automatically displayed on the same page.
Starting from version 9.3, you can see whether .gitlab-ci.yml
or .gitlab/route-map.yml
, as well as specific parsing errors. It also analyzes the LICENSE
file, which makes it easier to access information about a specific license if you need additional details. And in order to understand what projects are based on, you can explore dependency management systems, which are now also automatically displayed.
Ah, packets, these precious pieces of wisdom, assembled and ready for use. GitLab now automatically detects and links directories in the file browser, saving you clicks every day. Elegant, right?
*.gemspec
(Ruby)package.json
(Node.js)composer.json
(PHP)Podfile
(Objective-C)*.podspec
(Objective-C)*.podspec.json
(Objective-C)Cartfile
(Objective-C)Godeps.json
(Go)requirements.txt
(Python)In GitLab 9.2, we released pipelines on a schedule that can be customized using the user interface. In GitLab 9.3, we also added the ability to create and manage pipelines on a schedule through a set of APIs to make integration with other tools easier and more efficient.
More information in the documentation about the API pipelines on schedule.
In the previous version of GitLab, we added the ability to see the effect of a merge-request on memory right on the page of a merge-request. In GitLab 9.3, we decided to go further: now we measure changes in average memory usage 30 minutes before merge and 30 minutes after it.
Developers have become easier than ever to know about the impact of their actions on performance due to direct feedback from the tools they use every day.
Read more in the documentation about monitoring applications with Prometheus.
Also with this release we released GitLab Runner 9.3.
GIT_CHECKOUT
, which controls the execution of git checkout ( merge-request )cpus
option in the Docker executor ( merge-request )userns
option in Docker executor ( merge-request )A list of all the changes you will find in CHANGELOG .
Full documentation on GitLab Runner .
In GitLab 9.0, monitoring of the GitLab service was introduced using Prometheus , with which you can evaluate the performance of Redis, PostgreSQL, and the system as a whole.
As part of GitLab 9.3, we added an experimental ruby ​​codebase monitoring service. While it displays only a few indicators like the status of the pipeline and user authentication. In future releases, we will add monitoring to other parts of GitLab.
For more information, see the additional metrics documentation.
Detailed release notes and instructions for updating / installing can be found in the original English post: https://about.gitlab.com/2017/06/22/gitlab-9-3-released/
Translation from English is made by translational artel "Nadmozg and partners", http://nadmosq.ru . Rishavant and sgnl_05 worked on the translation .
Source: https://habr.com/ru/post/332204/
All Articles