GitLab 8.16 released: Support for Google Container Engine, built-in Prometheus + time tracking in CE

The story of the removal of the base of course eclipsed all the other news about GitLab. So if you missed a release post about changes and new features in GitLab 8.16, below is its translation:

Our goal is to make development participation accessible to everyone . To do this, we make the GitLab toolkit easy to use, configure, and maintain. In the previous version of GitLab, we implemented simple configuration of continuous integration (continuous integration, CI) and automatic deployment (deploy) in Kubernetes. And in the first release of the new year we are taking the next step towards our goal.

In GitLab, we try to embody the principle “from idea to production” (“idea to production”): one system should serve all stages of development from discussing the idea to its implementation, deployment in a combat environment and operation.

Starting from version 8.16, GitLab will be able to work with Kubernetes in Google Cloud. Also now GitLab will include a powerful monitoring tool called Prometheus .

You can not just deploy the application and forget about it - you need feedback on the results of the deployment. It will roll back a failed deployment and provide material for improving the process. GitLab should give you feedback on the system, application, and business metrics directly through the deployment tools. Prometheus - the first step to the implementation of this task.

The MVP of this month, which expanded the statistics on the use of persistent memory - Markus Koller . Thank you, Markus!

Meeting in Cancun and prototype on Google Container Engine (GKE)

Every nine months, all members of the GitLab team and their families gather at our summit .

There we personally meet and communicate, share ideas and plans in an informal setting. Just passed a summit in the Mexican city of Cancun. There, the CEO of Sid Sijbrandij shared his vision of the past, present and future of GitLab:

This is an internal presentation, the main audience of which is the members of our team. However, we publish it because transparency is one of our core values . You should not take it as an official statement, we are still discussing some issues like GitLab.com subscription plans.

If you do not have time to watch the entire video, look at least a fragment at 44:48 , where Sid offers his colleagues a bet:

"If you are the first to implement a working prototype" from idea to production "on the Google Container Engine (GKE), I will be so glad that I will dance the dance of the sloth Sid from Ice Age 4 (Sid Shuffle)."

Even if you did not see this dance in the original, you will surely like it. But first, let's see what is the meaning of this bet.

Last month ( translation , original ) we showed you how the development process will look in the near future.

In just a few minutes, with only the container scheduler, you can build an application deployment system from GitLab to a Kubernetes cluster with scalable continuous integration (CI) capabilities.

Google Container Engine is part of Google Cloud, the use of which is accessible to everyone. But getting it to work is not an easy task. Our developers have tried their best to solve it.

They were motivated both by the opportunity to make a cool feature for all our users, and by the desire to see Sid's dance.

As a result, GitLab 8.16 can be deployed to the Google Container Engine. It will immediately have an auto-scalable CI, automatic deployment to your own Kubernetes cluster, Mattermost chats, support for the private Docker registry, and certificate setup using Let's Encrypt:

And in this video, our developers demonstrate a working prototype, and then Sid performs his part of the deal. If Sid interests you more than a demonstration, look immediately from 28:29 .

More about deployment in GKE

All that was shown in the second video, we can do right now.

Sign up for Google Cloud and follow the instructions in the documentation for idea to production on Google Container Engine .

To work with Kubernetes, use the automatic deployment configuration documentation.

We are working to make the implementation of the “idea to production” principle easier and more accessible for everyone.

Monitoring GitLab with Prometheus

Earlier we shared our plans for implementing a world-class monitoring system in GitLab. In version 8.16, we begin to translate these plans into reality. This release includes Prometheus and its Node Exporter as part of the Omnibus package. With their help, it became possible to conduct high-quality time monitoring of the resources of your GitLab server.

In this release, Prometheus and Node Exporter are disabled by default, but starting with GitLab 9.0, we plan to enable them by default. Exit GitLab 9.0 is scheduled for March 22.

To enable monitoring in the current version, simply connect the appropriate features and reconfigure GitLab.

After turning on Prometheus, you can connect to <your_domain_name>:9090 to access the Prometheus console, or use third-party utilities, such as Grafana.

In the coming months , more graphs will be added to the deployment environment pages, for example, to assess the impact of the deployment process on memory usage .

CE time tracking system and its software interface

A time tracking system was introduced in GitLab 8.14 Enterprise Edition, which is very popular. Many users expressed the opinion that this system is important not only for large companies, but also for small development teams. We have listened to your opinion: since version 8.16, the time tracking system has moved to Community Edition.

Moreover, the time tracking system now has a full-fledged API, providing the same functionality as the user. Thanks to this, you can now estimate the time spent on certain tasks and Merge-Requests.

Timekeeping documentation



API Documentation for Merge Requests and Tasks

GitLab Pages at 8.17

We promised to move GitLab Pages to CE and started working on it . We are planning to finish by GitLab 8.17 next month.

New interface for searching and filtering tasks

If you use tasks, most likely you have a lot of them. For your convenience, we have added to GitLab the ability to search and filter tasks based on their properties. In version 8.16, we changed the design of this interface, making it more intuitive, and at the same time modernized its appearance. It will also expand the search and filtering functionality in the future.

We started with tasks, but we plan to transfer the updated design to other components of GitLab soon.

Cancel approval of merchandising in GitLab EE

In GitLab Enterprise Edition Starter, there is the possibility of approving merge-requests. Until now, this action was irreversible, and in fact there are many situations in which approval would be desirable to cancel.

Maybe you saw something in the differential that you missed earlier, or maybe, by the merge-request, there were new questions from other team members, and until these issues are resolved, approval should be removed.

GitLab 8.16 EE now has the ability to do this. To cancel approval, simply click on the merge request widget. Both with the approval of the request and with the withdrawal of approval, system notes are written in the discussion of the merge-request, and letters with notifications are sent.

An updated version of the approval system is available on GitLab Enterprise Edition Starter, Premium and on GitLab.com.

Write Access Deployment Keys

Deployment keys (deploy keys) are ideal for issuing limited read access to your repository from the outside, for example when deploying.

We added the ability to issue write access with deployment keys. This will allow the owner of such a key to push to your repository, which can be useful when installing the Git tag when deploying, pushing assembly artifacts to the repository, etc.

By default, deployment keys give read-only access; existing keys will not change.

Alien Ibrahim has added the key functionality to write access. Thank you, Ali!

Restrictions on the use of Shared Runner (EE Starter / Premium)

Not only does GitLab CI automatically scale to any request, generic Runner makes it much easier to integrate CI into an entire organization. In essence, offering CI services is so simple that we have realized the tremendous need to limit the use of shared resources.

With GitLab 8.16 Enterprise Edition, you can limit the build time for a common Runner group. Once going beyond the limits of the limit, the pipelines will no longer run on common Runners. This will prevent you from reusing shared resources when using GitLab CI.

Learn more about limiting the minutes of building Shared Runners.

Introducing the new slash /merge command for merge requests

Slash commands are a very fast way to perform a group of operations on tasks and merge-requests in GitLab. Just type one of the commands in the description or comments of the task or the merge-request, and the commands will be executed as soon as you press Enter.

With slash commands, you can even merge. Add /merge and merge-request will be executed when it is ready, if you have permission to do so.

There are a lot of slash commands in GitLab, you can see them all here.

Modifying the navigation and project settings

In GitLab, we do short iterations. Therefore, from time to time we think over again and modernize our settings and navigation.

In GitLab 8.15, the project settings drop-down menu consists of many items. Moreover, we were confused a little by the fact that the menu itself is located far from the navigation tabs in the center of the page. In the next few releases, we will modify the navigation and group the settings as needed.

At 8.16 we just started these changes, merging the menu items Members and Groups into one. Moving to a new page will show both of these pages on one. In the same way, we combined Webhooks and Services in Integrations .

Mark and show the date of the last used SSH keys

If you downloaded several SSH keys, it may be difficult to tell which one you used last.

GitLab now reports which SSH key was last used. This information can be found in your profile in the keys: /profile/keys .

Thanks to Vincent Wong for developing such a useful feature!

Storage statistics

OK, we recognize: we are doing our best to use as much disk space as possible. You can use GitLab to store build artifacts, your Docker images, LFS objects, Git blobs, etc.

To make it a bit easier to see what your disk space is going to, GitLab now reports on the project and groups how much disk space was used and what (repositories, artifacts (including Docker images) or LFS).

For this feature, thanks to this month’s MVP Markus Koller !

Gitlab runner

Also today we are releasing GitLab Runner 1.10. The most interesting changes:

• Added termination of grace period for Kubernetes executor ! 383
• Added settings for requests for resources Kubernetes ! 391
• Added polling interval and timeout parameters for Kubernetes executor ! 384
• Passed ImagePullSecrets for Kubernetes executor ! 449
• Added the ability to rewrite the Kubernetes executor namespace ! 444
• Added support for GIT_SUBMODULE_STRATEGY ! 443
• Added Prometheus metric, which counts the number of errors found ! 439
• Updated Docker Machine in official Runner images to version 0.9.0 ! 454
• Added command line option for runners '--run-tagged-only' ! 438
• Added armv6l to the list of replacements in ARM for the docker launch assistant image ! 446

For a complete list of changes, read the Runner CHANGELOG file .

GitLab Mattermost 3.6

GitLab 8.16 includes the Mattermost 3.6 , an open source alternative to Slack , the new release of which offers improved multi-command deployment, the first version of emoji reactions, an improved command line interface, and much more.

This version includes security updates . We recommend to update.

---

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

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