GitLab 9.4 released: Related tasks and web monitoring applications

In GitLab 9.4, we present related tasks, web monitoring applications, updated navigation, group milestones and much more!

It is difficult to surprise someone when you work openly. But this approach allows us to talk about the reasons for our innovations, as well as explain how they will make GitLab even better in the future.

In addition to adding new functionality, GitLab 9.4 also lays the groundwork for many future innovations. Now you can officially associate tasks with each other , the functionality of variables in CI is seriously expanded, and the monitoring system, without additional settings, analyzes much more metrics .

Moreover, we give you the opportunity to look into the future with the help of an optional beta version of the new navigation system . We hope that working together with users will help us make improvements that everyone will like.

In addition to this, we add simple and intuitive integration with Trello using GitLab PowerUp for Trello .

Also, continuing to talk about integration, version 9.4 includes a new Slack application for GitLab .

And if one quick glance is not enough, we are working to implement the full automation of DevOps toolkit customization with Auto DevOps . This functionality provides a complete analysis of your application and automatically adjusts its assembly, testing and deployment in Kubernetes. You can watch the progress of work on the Auto DevOps overview page .

We invite to our meeting!

This month's MVP is Matt Gresko

Matt added support for EC2 profile credentials when using AWS elasticsearch clusters; previously only static IAM data could be used. This is a complex job that greatly improves the integration of GitLab with elasticsearch . Thanks to these innovations, some aspects of our Improved Global Search are configured automatically when GitLab is running on AWS.

Matt also worked on the initial implementation of AWS . Thanks, Matt!

Related Tasks (EES, EEP)

When adding a link to one task from another, GitLab automatically shortens it and creates a cross-reference. But, as tasks grow and projects become more and more complex, it becomes more difficult to track links and quickly find the right tasks.

To solve this problem, we introduce the functionality of related tasks. Now you can declare tasks related to each other, after which a description of each task will display a link to another, as well as its status and name.

To create such a link, simply add a link to the task that you want to link to the current one, or find it in the search by typing # (you could have done so before). In the future, we plan to add other types of relationships between tasks using this mechanism.

More information on related tasks in our documentation.

Updated navigation (CE, EES, EEP)

We strive to make working with GitLab as easy and fast as possible, so we are working on navigation updates. Since changes to navigation can be confusing at first, we release the first stage of updates as an optional configuration of GitLab 9.4.

To enable it, click on your profile icon in the upper right corner of the screen and select Turn on new navigation .

We made changes to the global navigation at the top of the screen, and also entered contextual navigation in the left menu - its content depends on which page you are on. Work continues on the new interface; it will finally replace the current navigation option in the next few months. Information about the process of its development, as well as what remains to be done, is in this post .

We welcome feedback .

More information on navigation updates in [our documentation]

Web monitoring applications (CE, EES, EEP)

In GitLab 9.0, we released a performance monitoring system integrated with a CI / CD deployment, collecting statistics (CPU and memory usage) of applications deployed on Kubernetes. It was a successful first step, and now we are launching web-monitoring applications, supporting not only Kubernetes.

GitLab now automatically tracks key indicators that affect system experience, such as throughput, error rate, and latency. Simply connect Prometheus to one of the supported load balancers or HTTP servers , and statistics tracking will start automatically.

It is very important that work with the system is simple and intuitive. GitLab is now even closer to this, thanks to the inclusion of performance feedback in the tool that developers use every day.

More information on web monitoring applications in our documentation.

Group Level Secret Variables (CE, EES, EEP)

Secret variables are very useful in situations where you need a place to safely store important information. Until now, secret variables have been stored at the project level. However, we know that different projects in the same group often store general deployment information, as well as credentials for accessing external services.

Thanks to the introduction of secret group-level variables, the need to duplicate variables between projects disappears: now it is enough to enter data once, and each project or subgroup in the group will automatically open access to them. It’s also easy to update this data: just change it in one place and it will automatically update for all projects.

More information about group-level secret variables in our documentation.

Variables in pipeline schedules (CE, EES, EEP)

In GitLab 9.2 we added schedules of pipelines , thanks to which you can configure automatic start of pipelines at certain time intervals. In addition to this, many teams want to be able to set values ​​for certain variables when executing a schedule.

In GitLab 9.4, we add the ability to define variables when creating or modifying a pipeline schedule: these values ​​will be added to all already defined variables. With this functionality, you can also override existing variables for a particular run, for example, you can change the execution of tests by a specific pipeline for one day.

More information about variables in pipeline schedules in our documentation.

Environment Secret Variables (EEP)

Using variables to determine the values ​​used when deploying to certain specific environments is often the right solution. Since different environments (for example, staging and production ) may require different variable values ​​to perform the same task (for example, application name), it is important to create a direct link between some variables and the corresponding environment.

In GitLab 9.4, secret variables for environments have been added to solve this problem; developers can now specify which environments will receive a particular variable. You can even include dynamic environments, for example, review/ . So now you can easily deploy to various environments.

More information about secret variables for environments in our documentation.

GitLab Power-Up for Trello (CE, EES, EEP)

Using both Trello and GitLab? Now it's even easier thanks to the new GitLab Power-Up ! To connect it in Trello, go to the Power-Ups section and find the Power-Up GitLab . After setup, you can attach GitLab Merge Requests directly to Trello cards.

In Trello, you will need to set up your domain, for example gitlab.com/api/v4 for GitLab.com, and also add your personal token.

More information about GitLab Power-Up for Trello in our documentation.

GitLab Slack application for GitLab (CE, EES, EEP)

GitLab is already deeply connected with Slack (and Mattermost , Microsoft Teams and HipChat ), but we still haven't had an application in the Slack application directory. Now we have it! Integrating Slack into your GitLab.com projects has become much easier.

You can set up integration with the application from the project settings in GitLab ( Settings> Integrations ). Soon it will also be available from the Slack directory itself. Together with Slack, we are working to ensure that private instances will be able to use the same Slack application in the near future. And, of course, private instances can be integrated with Slack manually through the steps described in the documentation .

Read more in the documentation about the GitLab Slack application for GitLab.com.

Other improvements in GitLab 9.4

Improved localization (CE, EES, EEP)

We are gradually accelerating with the localization of GitLab. Many thanks to the members of our community who have contributed to the addition of additional languages ​​- Chinese, French, Japanese and Brazilian Portuguese. Thank you so much Huang Tao for your constant contribution to this business!

In GitLab 9.4, we added support localization for the commits page.

Read more about localization in our guide.

Group Milestones (CE, EES, EEP)

The Milstone is one of the main parts of tracking tasks. They are often used to mark sprints (week 35), releases (version 9.4), or category (backlog) of tasks and merge-requests. Often the milestones cover several projects: you have the ability to quickly create milestones for several projects at once. Now it's even better: we added the ability to create group milestones .

Group Milestones behave in the same way as their counterparts - project Milestone , but are created in a group and from there are available for all projects directly belonging to this (parent) project.

To create a group mailstone, go to your group, click Issues , and then Milestones .

Read more in the documentation of the group milestones.

GitLab Geo Improvements (EEP)

Important changes:

• GitLab Geo now supports PostgreSQL replication slots to prevent secondary Geo nodes from being out of sync with primary nodes. How exactly to use it in primary nodes - see the documentation .
• We improved the performance of Git data replication by adding additional concurrent cloning operations .
• Geo now comes with the original version of the event log cursor, which allows you to use the secondary track when you need to update your Git repository. In the future, we will ban the use of Geo system hooks.

GitLab Geo Documentation

Object storage for CI artifacts (EEP)

Companies continue to implement CI / CD throughout the organization, and their artifact repositories are also growing. In GitLab 9.4, you can move existing CI artifacts in Amazon S3 to free up additional local space and efficiently and reliably store as many artifacts as you like. Now you need to perform this operation every time you want to move your local artifacts to S3, but in the next iteration this will happen automatically, and all new artifacts will be saved to the object storage immediately after they are created - no manual migrations.

See the CI artifact documentation for details.

Advanced Docker configuration for CI / CD (CE, EES, EEP)

GitLab 9.4 introduces new and improved configuration options for .gitlab-ci.yml . They give you more flexibility in customizing the Docker images you want to use for your pipelines. To take advantage of these features, you will need GitLab Runner version 9.4 or higher.

Now you can define a special entry point for your Docker image (entry point) to override the default one. Below is an example of setting the entry point for /bin/sh - this will make the image suitable for GitLab CI works without additional modifications:

 image: name: super/sql:experimental entrypoint: ["/bin/sh"] 

You can also define aliases for services to run multiple parallel instances of the same Docker image, and define commands directly in the configuration file.

 services: - name: super/sql:latest command: ["/usr/bin/super-sql", "run"] alias: super-sql-1 - name: super/sql:latest alias: super-sql-2 

Details on changes in the Docker advanced configuration documentation

Security: added SSL certificate LDAP verification (CE, EES, EEP)

We added support for verifying an LDAP certificate over SSL. By default, this option will be disabled to ensure backward compatibility until GitLab 9.5 is released. In addition, to simplify the configuration of a secure connection, you can now define the CA certificate file and the SSL version. The names of the encryption methods ssl and tls turned into simple_tls and start_tls respectively.

Read LDAP documentation.

Customizable path for CI / CD settings (CE, EES, EEP)

GitLab defines the CI / CD settings in the YAML .gitlab-ci.yml file located in the repository root. There are times when you need to define a different location to define your pipelines — for example, when you mirror the SVN repository and cannot store files in the root of the project.

Starting with GitLab 9.4, you can define a special path in Settings> Pipelines by which the CI / CD settings will be read — instead of the .gitlab-ci.yml . The variable called $CI_CONFIG_PATH is available for jobs that need access to the current settings location.

Read the GitLab CI / CD documentation for details.

New caching policy for setting CI / CD (CE, EES, EEP)

By default, the caching process consists of downloading files, executing them and reloading them at the end. Any changes within this process will be saved for future launches. This is called a pull-push caching policy.

The default caching step consists of restoring and archiving the dependencies of your work, which speeds up the subsequent launch. If a change is made to the cached content, it will be written to the caching server by default - this is also a pull-push caching policy.

If you do not need to update the cached files in a particular job, you can skip the download step by setting policy: pull in the job settings. And if you have a job that always recreates the cache without referring to the previous content, you can use policy: push to avoid overloading the caching server. This functionality will require GitLab Runner version 9.4 or higher.

Read the GitLab CI / CD documentation.

Upcoming signing of Omnibus packages (CE, EES, EEP)

Starting with the next release on August 22, we will sign all new packages. Along with the signed package 9.5.0, we will also provide signed versions of the last two releases (9.4 and 9.3).

Signing the packages adds confidence that the .deb and .rpm files needed to install GitLab have not been modified by anyone.

GitLab Runner 9.4 (CE, EES, EEP)

Also in this release we released GitLab Runner 9.4.

The most important changes are:

• Improved support for Kubernetes sections ( Merge-Request and Merge-Request )
• Support for caching policies in the .gitlab-ci.yml ( merge request )
• Advanced Docker configuration in the .gitlab-ci.yml ( merge request )
• In the unregister , the --all option was added ( merge-request )
• Switching to Go 1.8 ( merge-request )

For a complete list of changes, see the CHANGELOG GitLab Runner.

Full documentation for GitLab Runner

---

Detailed release notes and instructions for updating / installing can be found in the original English post: https://about.gitlab.com/2017/07/22/gitlab-9-4-released/

Translation from English is made by translational artel "Nadmozg and partners", http://nadmosq.ru . Rishavant and sgnl_05 worked on the translation .