GitLab 10.0 released: Auto-DevOps and group task boards

GitLab 10.0 came out with Auto-DevOps, group task boards, new navigation and many other features.

From the formulation of ideas - to launch and monitoring in production. DevOps sets the culture and environment in which software development, testing, and release occur faster, more often, and more reliably.

GitLab 10.0 makes it easier to learn DevOps using the Auto-DevOps functionality , which will allow your team to easily embed and configure modern development practices into your workflow.
In addition, GitLab has updated navigation and a new way of interaction between different groups (teams) has appeared.

Every month in the next version of GitLab we add new features and improve old ones. GitLab 10.0 is no exception.
Thanks to the contribution of our opensource community, the opportunity to automatically resolve outdated discussions in merge requests has appeared , subgroups have improved, an API has appeared for Wiki pages

The task management capabilities in GitLab improve with each release.
Filtering and searching by tasks in different groups has improved significantly , the updated interface makes it easier to access task transfers . In addition, moving tasks can be accelerated with slash commands .

If you are using GitLab Enterprise Edition and JIRA, you can now view GitLab commits and branches directly from the JIRA interface.

We continue to improve the security and performance of GitLab.
Now the administrator can restrict SSH access using the algorithm and key length.
LDAP group synchronization (Group Sync) can now be automated using the API . She also received improvements in regulating access by external users .
The performance also improved: the speed of loading pages, creating projects and processing commits increased, and the consumption of RAM decreased.

We invite to our meetings!

MVP of the month - Hiroyuki Sato

This month, members of our community again offered a huge amount of improvements . This brings substantial benefits to GitLab and all its users, and once again shows the power of the opensource community.

Hiroyuki Sato offered a number of features in GitLab 10.0: performance improvements, search, task filtering, and Merge Requests. Our favorite feature is the filtering of tasks and merge-requests for your reaction to them . With it, you can once again look at everything that you liked (and what is not - too).

We thank all participants for the work done, and especially - Hiroyuki Sato.

Auto-DevOps (CE, ESS, EEP)

Auto-DevOps brings the best development practices to your project. This feature allows you to automatically configure the assembly, testing, quality control code, applications for reviews, deployment and monitoring of each individual environment.
In GitLab 10.0, ready-made templates appeared with which you can quickly set up the entire application life cycle in DevOps standards. These templates are based on GitLab CI / CD .

GitLab offers a unified environment in which changing the code generates not only the assembly, but also the deployment of your product as a special application for review . It will allow you to look at the changes made by each merge request before accepting it. Recently, GitLab has the opportunity to measure code quality indicators . Thanks to this you will be able to track their changes when reviewing the code.

After a successful review, GitLab will allow you to release a “canary” or regular release of your application into the combat environment. With GitLab Auto Deploy, you can also set up deployment to Google Cloud.
GitLab Auto Monitoring helps you collect metrics for system resource usage and performance for each deployed version of the application.

All these processes are aggregated and automated in GitLab 10.0 using Auto-DevOps. All this is done to make your way from idea to implementation as short as possible.

Auto-DevOps automatically detects, builds , tests, deploys, and monitors applications. Thanks to Herokuish support , this feature works with all languages ​​and frameworks available in Heroku buildpacks: Ruby, Rails, Node, PHP, Python and Java. You can also customize your own build packages. Read the introductory guide - it will help you get started and get started faster.

Auto-DevOps is now released in beta. We recommend waiting using it in production.

By the way, GitLab is not affiliated with Heroku or Glider Labs.

Be sure to read the Auto-DevOps documentation .

Group task boards (EEP)

Many development teams use the same GitLab group and are working on many projects in this group. For example, many companies are introducing or have already implemented microservice architecture. The code for each microservice is stored in a separate repository, which is located in a separate GitLab project . It turns out that the team works with related tasks in a variety of projects and repositories. It will be very convenient to manage all these tasks in one place.

In this release, we proudly release the feature that you have long wanted - group task boards .

Now you can manage the tasks of all projects belonging to a group on one screen, using lists, tags and mailstore shared for the entire group.

To learn more about group task boards, read the documentation.

New GitLab interface (CE, EES, EEP)

In the new version, the GitLab interface has completely changed to make navigation easier and faster.

Over the past few months, we have been testing fundamentally new ways to navigate GitLab. We conducted user testing, studied feedback, and found that the existing interface was causing a number of navigation problems. The group and project that the user viewed were not always obvious. It was difficult to switch between different parts of GitLab. The page hierarchy was inconsistent, which confused users.

In the new GitLab 10.0, navigation has become more consistent. The top panel reflects all global and personal aspects: your groups, projects, tasks, merge-requests, todo-tasks and personal information. The left pane depends on the context: on the group or project you are viewing. All the menus in this panel are expanded when you hover the cursor - now you do not have to wait until the intermediate page loads to click on another link on it.

By the way, you can again choose a color scheme to your liking. Still, not everyone loves the color purple as we love it.

More on navigation in the GitLab blog.

GitLab Protected Handlers

In CI / CD pipelines there are tasks that require increased security. For example, when deployed in a combat environment, credentials or configuration settings are used that should not leak. To protect them, you can mark a specific handler (GitLab Runner) with a “protected” flag. Then only pipelines for commits from protected branches will be executed on this handler.

Use this feature together with the mandatory confirmation of merge-requests and the choice of handler for the tag .
Then you will be sure that only trusted code is executed on the protected handler.

For more information, see the GitLab protected handlers documentation.

Object Storage for Git LFS (EEP)

Git LFS allows you to efficiently version large files with Git.

But large files, which is quite unexpected, take up a lot of disk space. The more of them, the harder it becomes to keep them.

GitLab Enterprise Edition Premium now allows you to store LFS files in object storage, for example, in Minio or Amazon S3 .

To learn more about this feature, read the documentation .

Requirements for SSH-keys (CE, EES, EEP)

Thanks to the contribution of Corey Hinshaw, the GitLab administrator can now customize the requirements for the SSH keys used. Each of the possible encryption algorithms can be:

• ban
• allow or
• allow with the minimum required key length.

This will allow you to GitLab.

Other GitLab 10.0 Improvements

API for working with wiki pages (CE, EES, EEP)

Now GitLab API can be used to work with wiki-pages. The API will allow you to get a list of wiki pages and the contents of a specific page, create a new page, edit or delete it. All this allows you to fully work with wiki-pages from the program code.

We thank the member of our community Vitaly Klachkova for this contribution.

API documentation for working with wiki pages

GitLab Runner 10.0 (CE, EES, EEP)

Also with GitLab 10.0 we release GitLab Runner 10.0. GitLab Runner is an open source project used to run your CI / CD tasks and send the results back to GitLab.

The most important changes are:

• Registration team reserves Runner for project by default
• Added processing of non-existing images for the Docker version> = 17.07
• Fixed issue with variable file permissions using Kubernetes executor

A complete list of changes can be found in the GitLab Runner changelog .

Read the GitLab Runner documentation.

GitLab Runner is reserved by default for a project (CE, EES, EEP)

During the initial registration of a new handler (GitLab Runner), you will be asked if you want to reserve it for a project (lock to the project) , the token of which you provide. In previous versions, the default was false , but it was not clear that this allows any project owner to use this handler for other projects, which is a serious security risk. Starting from GitLab 10.0, true selected by default, so the handler cannot be simply implemented in other projects.

If necessary, this can be changed later in the handler settings. And, of course, mark it manually when registering via the UI or using the option --locked=false via the console.

Read the handler registration process documentation.

Simplified project permissions (CE, EES, EEP)

One of the distinguishing features of GitLab is the granularity of the access rights to the project capabilities.

In GitLab 10.0, we have simplified the user interface, allowing you to even more easily control the scope of your project, features and access rights - and do it in a convenient interface.

Learn more in the simplified access rights documentation for projects.

Improved access rights for subgroups (CE, EES, EEP)

In GitLab 9.0, we released subgroups that made the process of organizing projects and groups inside GitLab more flexible. If you have not tried them yet, you can find out the details of the subgroups in our documentation .

In this release, we added the ability for owners to allow the creation of subgroups, even if the creation of a group was prohibited. This will simplify the management of the structure of GitLab groups for users who have delegated this responsibility.

Subgroup documentation

Access to commits and GitLab branches in the JIRA development panel (EEP)

Many GitLab users also use JIRA. In this release, we have significantly improved integration with JIRA and present GitLab commits and branches related to tasks in the JIRA development panel . While working on a task in JIRA, you can quickly switch to the commits or branches associated with this task in GitLab - the integration between them has become even closer.

See the JIRA dashboard integration documentation for details.

Time tracking for exporting tasks to CSV (EES, EEP)

In the functionality of exporting existing tasks to CSV, we added the ability to track time (estimated and elapsed). This allows team leaders and managers to easily track time information using tables.

Thank you Bohdan V. for this opportunity.

Read more in the documentation about exporting to CSV.

Reaction filter (CE, EES, EEP)

Now when filtering tasks in GitLab or Merge-Requests, you can select a filter by the reactions you left. This can be used as generalized bookmarks. Just react to the task or merge-request, assigning them different emoji - and you can quickly access them through such a filter.

For this feature, thanks Hiroyuki Sato .

Read the search and filtering documentation in GitLab

Quick action to move a task (CE, EES, EEP)

To further speed up your workflow, GitLab has a special slash command for quickly moving a task. Now you can move the task while writing a comment.

Thank you, Manolis , for your contribution.

Read the quick action documentation.

Redesign of system notes icons (CE, EES, EEP)

We continue to define and highlight the individual style of GitLab . This time we made a redesign for the system notes icons.

Look at the set of our new beautiful icons.

Improved monitoring board (CE, EES, EEP)

We have significantly improved the environment monitoring board, making its appearance more comfortable, as well as adding support for several series in one graph. It helps to better understand performance efficiency and makes it easy to compare. For example, application bandwidth can be broken down by HTTP response codes, and you will see one graph with successful and failed requests, as well as potentially missing pages.

More information about monitoring environments using Prometheus in our documentation.

LDAP Group Sync API (EES, EEP)

Synchronizing LDAP groups in GitLab is now available using the API, allowing you to programmatically request a synchronization event. This means that any group automation, for example, creating groups via an API, can be immediately programmatically synchronized with LDAP using one small API request.

API group GitLab Enterprise Edition

Configuring LDAP "verify_certificates" for security (CE, EES, EEP)

The LDAP verify_certificates now activated by default for security reasons. This setting appeared in 9.4.2, but was turned off by default for backward compatibility.

There are settings that use start_tls or simple_tls for the encryption parameter, and for some reason, the SSL protocol is not properly configured between the LDAP server and the GitLab server. Such installations may break if the SSL certificate of the LDAP server is not accepted by the GitLab server.

Read LDAP admin documentation.

Upgraded installation of Omnibus GitLab (CE, EES, EEP)

Installing GitLab is now easier and faster than ever before! GitLab 10 allows you to specify the URL to which GitLab will be available, directly during the installation of the package. After that, GitLab will automatically migrate to the desired URL and start, skipping two steps from the installation process.

See the Omnibus GitLab documentation for details.

Omnibus Improvements (CE, EES, EEP)

• Updated Ruby to 2.3.5 .
• libyaml updated to 0.1.7 .

Read the Omnibus GitLab documentation

GitLab Mattermost 4.2 (CE, EES, EEP)

GitLab 10.0 includes the Mattermost 4.2 , an open source alternative to Slack . The new release has interactive message buttons - to simplify complex workflows - and more.

This version includes security updates . We recommend to upgrade.

GitLab Mattermost Documentation

Review of the week for analytics development cycle (CE, EES, EEP)

Design cycle analytics measure the time from idea to production for each of your projects. This is achieved not only by indicating the total time to reach a certain point - the total time is divided into different stages, which the idea passes before its final release.

Thanks to a member of our community, Mehdi Lahmam , it has now become possible to review your performance over a 7-day period, which is especially useful for teams with short development iterations.

Complete cyclical analytics documentation

New GitLab Runner Repository (CE, EES, EEP)

September 12, 2017 we moved GitLab Runner to a new repository. From now on, Runner is available on https://gitlab.com/gitlab-org/gitlab-runner .

Do not forget to update your bookmarks!

Predefined variables for user identification (CE, EES, EEP)

When using pipelines, there are many environment variables that GitLab sets automatically. This gives your scripts the opportunity to receive important information. In GitLab 10.0, 2 new variables appeared, GITLAB_USER_NAME and GITLAB_USER_LOGIN , allowing you to get the full name and login of the account that started the work.

Read the documentation about predefined variables for CI.

Variables for pipeline API on schedule (CE, EES, EEP)

In GitLab 9.2, we introduced pipelines on a schedule , and in the next releases we added API and variable support. In GitLab 10.0, we end the loop by adding support for variables to the API requests as well. Now the automatic interaction of third-party applications with pipelines on schedule will be more flexible.

You can read the sub-items in the variable documentation for the pipeline API on a schedule.

Access lock for subgroups (CE, EES, EEP)

GitLab provides an opportunity to share projects between different groups, which makes the project structure and permissions more flexible.

Blocking access provides the ability to protect against sharing projects in certain groups, in order to ensure compliance with the company's security policy.

Now blocking access is also possible for subgroups. This allows subgroups to inherit or redefine access blocking from the parent group, which makes control over the distribution of projects more accurate.

For more information, see the access lock documentation.

Special page for technical support tasks (EEP)

Previously, to manage technical support tasks, it was necessary to search for tasks created by a special bot on the project task page. Now there is a separate page in the navigation where all such tasks are collected automatically. Also on the page is displayed email support - this makes it easy to share it with any person who needs to send a request to tech support.

Read more in the technical support documentation.

Menu filtering and search for group Merge-Requests (CE, EES, EEP)

We updated the page with a list of merge requisitions and added a search and filter menu to it in a fresh design. This will allow you to quickly sort the list of necessary requests by author, artist, mailstone, label or weight - the same thing that you can do with tasks for a long time.

For this menu, thanks Hiroyuki Sato .

Find out more in the Merge Group Requests documentation.

Moving tasks in the sidebar (CE, EES, EEP)

The task transfer functionality has moved to the task side menu. We group other important actions and free up the main task space so that in this space it is easier to concentrate on the name and description of the task.

Details in the documentation on moving tasks

Merzh-request inherits tags and milston tasks (CE, EES, EEP)

If you use Mailstone and tags for your Merge-Requests, you probably often have to copy them from the task to the Merge-Retrieve associated with it. Now when creating a merge-request from a task using the appropriate button, the merge-request automatically inherits mailstone and tags.

Haseeb , thank you for your contribution!

On the creation of new requests for merger, read our documentation.

Automatic resolution of outdated merge-request discussions (CE, EES, EEP)

For some users, allowing merge-request discussion means simply inserting a new code instead of the code in question. We present a merge request setting specifically for this. If this setting is enabled, any defamation discussions will be resolved if after the next push this defamation section becomes outdated. Note that discussions in those lines that do not change, as well as high-level discussions will not be resolved automatically.

Thanks Ashley Dumaine for this feature.

Read the GitLab discussion documentation.

LDAP group synchronization enhancements for external users (EES, EEP)

LDAP group sync is available in GitLab Enterprise Edition and provides a great way to manage user permissions without any problems by modifying the system’s existing LDAP group and permissions.

GitLab also supports managing permissions for external users , which allows for more precise control of projects in each case.

In GitLab 10.0, synchronization of external users will occur during authorization - in addition to the existing periodic synchronization. This means that any changes in the permissions of your LDAP system will be available to the user immediately upon login, the settings will be updated automatically.

See the LDAP group sync documentation for details.

New filter for archived projects (CE, EES, EEP)

With the submission of a member of our community Mehdi Lahmam (and again, thanks to you!), It became possible to filter the project page so that only archived projects are displayed.

This can be useful when managing projects to see a complete list of all archived projects, and so administrators can easily delete them.

Read our GitLab search and filtering documentation.

Translated project activity page (CE, EES, EEP)

We continue to translate GitLab into new languages ​​and this time prepared a translation of the project activity page.

We recently created a translation community at CrowdIn. Now it will be easier for anyone to translate GitLab pages. If you want to connect, register through the community.

Include the GitLab translation

GitLab Geo Improvements (EEP)

Important changes introduced in GitLab 10.0:

• GitLab Geo completely replaces the use of system hooks. If you upgrade to GitLab 10.0, you MUST activate the search for SSH keys through the database . We recommend installing Geo to upgrade to CentOS 7.4 or use Ubuntu 16.04 to get the OpenSSH version.
• We have improved the Geo download scheduler to skip failed projects.
• , — “Advanced” ( ).
• .

GitLab Geo

(CE, EES, EEP)

— GitLab , . , GitLab, , GitLab.com, !

GitLab 10.0 , .

.

GitLab 10.0

PostgreSQL 9.2

GitLab 10.0 22 Postgres 9.2 Omnibus GitLab . Postgres, GitLab 10.0 9.6.

GitLab 9.0, 9.6. GitLab, , , .

PostgreSQL 9.2 , .

: 22 2017

API V3

GitLab 8.17 API v3.

API v3 GitLab.com.

API v3 GitLab 11 , API v4. API, .

: GitLab 11.0

GitLab , GitLab.

GitLab 10.0 . , , 11.0 — .

: GitLab 11.0

TLSv1

GitLab 10 TLSv1 . TLSv1, — nginx['ssl_protocols'] gitlab.rb .

: 22 2017

HTTP GitLab Git

GitLab 8.2, Gitlab Workhorse HTTP- Git. HTTP- GitLab Git . 10 , HTTP- GitLab Git. gitlab.rb , , GitLab .

: 22 2017

— , API .

GitLab API, , .

GitLab 10.2, , .

: 22 2017

SSH Git

Git GitLab SSH-, ~git/.ssh/config .id_rsa , .

. , , « GitLab».

: 22 2018

Git

GitLab 9.0 Git , . , . GitLab , gitlab.rb , git_data_dirs .

, gitlab.rb git_data_dirs({ "default" => "/var/opt/gitlab/git-data" }) , git_data_dirs({ "default" => { "path" => "/var/opt/gitlab/git-data" } }) .

: 22 2018

'types' '.gitlab-ci.yml'

types , stages , GitLab .

: 22 2018

GitLab.

: 22 2018

DevOps . DevOps Helm Charts , .

: 22 2017

«» . .

: 22 2018

'codeclimate'

GitLab Code Quality codeclimate . codequality , , codeclimate .

: 22 2018

Runner's 'docker-ssh' 'docker-ssh+machine' executors

executor'a GitLab Runner — docker-ssh docker-ssh+machine — . .

.

: 22 2018

GitLab Runner

( stop , start , restart , status , install , uninstall ). .

.

: 22 2018

release notes / : https://about.gitlab.com/2017/09/22/gitlab-10-0-released/

« », http://nadmosq.ru . rishavant nick_volynkin .