List of subscribed labels
Labels in GitLab are very powerful since they can be applied to issues, merge requests, and epics. As you use more labels, it can be difficult to maintain them.
In a recent previous release, we added the ability to search by labels on the project labels list page. With this release, you can now search by labels, sort by name/created at/updated at, and even see a list of labels you have subscribed to. This is available both in group and project labels list pages.
Filter by WIP merge requests
Merge requests are a core part of GitLab, allowing team members to collaborate on code transparently. In particular, we encourage teams to share their work early, and use the WIP (work in progress) feature to indicate that a merge request is still undergoing active work and should not be merged yet.
With this release, we’re making it easier for users to differentiate between WIP and non-WIP merge requests by having a dedicated filter in both group-level and project-level merge requests lists. This allows users to quickly focus in on merge requests that are still in their early stages of work, versus those that are toward the final stages of review before merge.
Highlight @mentions for yourself distinctly
When collaborating in a long discussion in an issue or merge request, often many users are involved, making it difficult to quickly at a glance, see comments that are directed at you.
With this release, @mentions for yourself (i.e. the current user), are highlighted in a different color, allowing you to easily see which comments involve you, helping you focus on them quickly.
Click to insert Markdown table and link
GitLab supports GitLab Flavored Markdown (GFM) in most places throughout GitLab where you enter text, providing the power of rich formatting with a simple syntax. In particular, you can create tables in GFM. Previously, this was painful to use, especially for large tables, since you had to type a lot of characters or paste in a previous table just to format it the way you want. Similarly, GFM also supports URL links. But sometimes you may forget the particular syntax.
With this release, you can now click on the table button in the GFM editor, and this will automatically insert a table for you. You can then easily enter table values or extend the table, formatting it just the way you want. You can use this in description and comment boxes all throughout GitLab.
You can now also click on the link button, and this will generate the URL link syntax skeleton for you. Allowing you to quickly paste in a link and write the name of it.
Thank you George Tsiolis for the table contribution!
Thank you Jan Beckmann for the URL link contribution!
Include new issues created in Burndown Chart
Burndown Charts help teams track work, as it progresses throughout a milestone. Usually, the scope of work is decided and agreed on before the milestone begins. But occasionally, there will be important exceptions to the rule, (such as an emergency bug or security fix) and new scope needs to be included, in the form of new issues.
With this release, burndown charts now accounts for these new issues that are created in the middle of a milestone, resulting in an uptick of its line.
Expanded weight values in issues API
In a previous release, we expanded the allowable values of issue weight from a small number to effectively unlimited, any number greater than zero.
With this release, we’ve brought this flexibility to the issues API as well, allowing users to set this field with the newly expanded number range with the API.
Lock discussion quick action
Locking discussions in issues and merge requests is helpful to direct conversations to newer issues (or merge requests). It can also be used to control abusive or otherwise unproductive behavior.
With this release, we now have quick actions to lock and unlock discussions, making it easier to type a comment and lock/unlock all one action.
Thank you Mehdi Lahmam for the contribution!
Close epics
Similar to issues and merge requests, you can now close (and re-open) epics in GitLab. The epics list now has the Open, Closed, and All tabs, just like issues. So when you have completed all the work in an epic, or it is no longer relevant, you can close it, and it won’t appear anymore in the default list view.
You can close (and re-open) an epic via buttons on the epic, via quick actions in an epic comment, and also via the API, exactly like issues.
Improve Admin Area settings structure
Depending on your responsibilities, administrating GitLab can provide a very complex challenge due to all things GitLab offers.
With this release, we improve the experience of our Admin Area Settings by moving all sections into new, individual Settings sub-pages. This provides admins a time-saving shortcut to access any detail to manage.
Explore projects by popularity
At GitLab, we do our best to enable you to explore relevant and cool projects on your GitLab instance. With this release, a new filter “Most stars” provides an incredible useful filter to show projects most starred on your instance.
Thank you for this contribution, Jacopo Beschi!
Display code language percentage on project overview
We recently introduced a new code language bar on the Project overview page, providing a quick overview about programming languages involved.
With GitLab 11.4, we introduce an additional absolute measure by showing a new percentage value for each relevant code language shown. This provides a more quantitative view of your project’s technology stack.
Thank you for this contribution, Johann Hubert Sonntagbauer!
Download two-factor recovery codes
Two-factor authentication is a de facto standard for signing up for any relevant web-based application. At GitLab we understand and take this seriously. Whenever you set up a two-factor authentication initially, we provide limited recovery codes that allow you to regain access to your account as a fallback.
With this release, we now support download of recovery codes as a text file using the new “Download codes” button.
Thank you for this contribution, Luke Picciau!
Filter admin Runners view by Runner type and state
The admin runner view now supports the ability to filter by runner type and state, giving you more options to manage especially large fleets of runners in your environment.
Add support for interactive web terminal to Docker executor
The interactive web terminals feature has been expanded to be compatible with Docker executors as well. For now, the Docker session is closed as soon as the script exits, but we are aiming to further improve this behavior by resolving #3605 in our next release.
Skip Auto DevOps jobs based on feature availability
Starting in 11.4 Auto DevOps will now evaluate the plan (GitLab.com) or tier (self-managed) for the instance in which it’s running in order to determine which jobs to skip. This will result in faster Auto DevOps pipeline when certain features are not in use.
This will not only save you time but will also result in a cleaner view of Auto DevOps pipeline, showing you only the relevant jobs for your project.
Allow pipelines to schedule delayed jobs
It is now possible to set a job to start after a delay via the when keyword in .gitlab-ci.yml. The timer starts ticking when the job would have otherwise started, giving you control to implement tasks that need to wait for a period of time to occur - for example, when implementing timed incremental rollouts, or any other delays needed after performing some other action.
Interactive runbooks with Nurtch and JupyterHub
Interactive runbooks provide a powerful way for operators to interact with various systems to carry out common tasks such as diagnosing, deploying, and measuring infrastructure components.
The JupyterHub app offered via GitLab’s Kubernetes integration now ships with Nurtch’s Rubix library, providing a simple way to create DevOps runbooks. A sample runbook is provided, showcasing common operations.
Add manual entries for License Management
License Management policy allows developers to define if they want to approve or blacklist a specific license for their project. This can be done as soon as a new license is introduced, directly in the merge request page. But sometimes project maintainers want to populate the list beforehand, so that developers already know if their changes are aligned with the policy.
In GitLab 11.4, we introduce the ability to add manual entries for License Management. Project maintainers can prefill the policy in the Settings > CI/CD > License Management page by choosing from a set of common licenses, or add a custom entry to that list.
Alert thresholds now displayed on metrics dashboard
With GitLab 11.4, configured alert thresholds are now displayed directly on the metrics charts. This allows easier determination of which metrics are currently generating alerts, and better visualization of the interplay of the metric and alert threshold.
Git protocol v2
Developers fetch refs many times a day to check if the current branch is behind the remote branch. Git protocol v2 is a major update to Git’s wire protocol which defines how clones, fetches, and pushes are communicated between the client (your computer) and the server (GitLab). The new wire protocol improves the performance of fetch commands and enables future protocol improvements.
Previously, all responses to fetch commands included a list of all references in the repository. For example, fetching updates for a single branch (e.g. git fetch origin master) would also retrieve a complete list of all references. In the case of large projects, this could be over 100,000 refs and 10s of megabytes of data.
Git protocol v2 is supported from Git v2.18.0 and is opt-in. To enable globally run git config --global protocol.version 2. Git protocol v2 over SSH is not yet enabled on GitLab.com and must be enabled manually.
Geo UX improvements in Admin Area
As a Geo admin, keeping an overview of your secondary nodes setup and the synchronization state is crucial when working with distributed teams.
With GitLab 11.4, we improve the Geo-related Admin Area settings by improving and showing even more synchronization and verification details in the user interface. On your primary node, a new button “Open projects” adds a new quick link to navigate to the “Projects” list of the corresponding secondary node. On secondary nodes, a new “All” tab gives you a quick overview about the verification state of all projects.
Further UX improvements are in our pipeline!
Prometheus 2.0 upgrade for Omnibus GitLab
Omnibus GitLab comes out of the box with Prometheus, allowing easy observability of deployed instances. The Prometheus team has released a major new version, the 2.x series, which offers a number of improvements. These include improved performance and a more efficient time-series database format. Unfortunately because of the architectural changes to the database, it is not backwards compatible with the old 1.x format.
With GitLab 11.4, Prometheus 2.4.2 is now available in the Omnibus package so users can take advantage of its benefits.
- New installations of 11.4 and above will start with Prometheus 2.
- Existing installations will not be automatically upgraded. We have added a new command,
gitlab-ctl prometheus-upgrade, which can be utilized to upgrade Prometheus and optionally migrate data. Prometheus will be stopped during data migration. - GitLab 12.0 will automatically upgrade to Prometheus 2.0. With the automatic upgrade, Prometheus 1.0 data will not be migrated.
For more information on upgrading Prometheus to 2.4.2, please review our update documentation.
Geo improvements
We continually focus on improving our Geo feature for distributed teams. Some of the additional noteworthy improvements in GitLab 11.4 include:
Read our fresh blog post on how we built GitLab Geo.
Geo improvements for SSH Git commands proxy to primary node
Making Geo as easy to use as possible is one of our constant goals to support widely distributed teams using GitLab. In 11.3 we added initial support for proxying SSH git push from secondary nodes to primary nodes.
With this release, we further improve the performance and usability of this feature, allowing to clone and push to projects in a Geo scenario without having to maintain multiple configurations or update the remote URL manually.
GitLab Runner 11.4
We’re also releasing GitLab Runner 11.4 today! GitLab Runner is the open source project that is used to run your CI/CD jobs and send the results back to GitLab.
Most interesting changes:
List of all changes can be found in GitLab Runner’s CHANGELOG.
Omnibus improvements
redis has been updated to 3.2.12, which is a critical security update that fixes multiple vulnerabilities. After upgrading to 11.4, run gitlab-ctl restart redis to ensure the new version is running.- GitLab 11.4 includes Mattermost 5.3, an open source Slack-alternative whose newest release includes enhanced search on desktop and mobile, plus much more. It includes security updates and upgrading is recommended.
git has been updated to 2.18.1, and libpng to 1.6.35.gnupg has been updated to 2.2.10, gpgme to 1.10.0, libgcrypt to 1.8.3, npth to 1.6, libgpg-error to 1.32, and libassuan to 2.5.1.- Certificates in the
trusted_certs directory are now set to 0644 permissions instead of 0755.
Some of the more noteworthy performance improvements in GitLab 11.4 include:
Filter by WIP merge requests
Merge requests are a core part of GitLab, allowing team members to collaborate on code transparently. In particular, we encourage teams to share their work early, and use the WIP (work in progress) feature to indicate that a merge request is still undergoing active work and should not be merged yet.
With this release, we’re making it easier for users to differentiate between WIP and non-WIP merge requests by having a dedicated filter in both group-level and project-level merge requests lists. This allows users to quickly focus in on merge requests that are still in their early stages of work, versus those that are toward the final stages of review before merge.
Click to insert Markdown table and link
GitLab supports GitLab Flavored Markdown (GFM) in most places throughout GitLab where you enter text, providing the power of rich formatting with a simple syntax. In particular, you can create tables in GFM. Previously, this was painful to use, especially for large tables, since you had to type a lot of characters or paste in a previous table just to format it the way you want. Similarly, GFM also supports URL links. But sometimes you may forget the particular syntax.
With this release, you can now click on the table button in the GFM editor, and this will automatically insert a table for you. You can then easily enter table values or extend the table, formatting it just the way you want. You can use this in description and comment boxes all throughout GitLab.
You can now also click on the link button, and this will generate the URL link syntax skeleton for you. Allowing you to quickly paste in a link and write the name of it.
Thank you George Tsiolis for the table contribution!
Thank you Jan Beckmann for the URL link contribution!
Expanded weight values in issues API
In a previous release, we expanded the allowable values of issue weight from a small number to effectively unlimited, any number greater than zero.
With this release, we’ve brought this flexibility to the issues API as well, allowing users to set this field with the newly expanded number range with the API.
Close epics
Similar to issues and merge requests, you can now close (and re-open) epics in GitLab. The epics list now has the Open, Closed, and All tabs, just like issues. So when you have completed all the work in an epic, or it is no longer relevant, you can close it, and it won’t appear anymore in the default list view.
You can close (and re-open) an epic via buttons on the epic, via quick actions in an epic comment, and also via the API, exactly like issues.
Explore projects by popularity
At GitLab, we do our best to enable you to explore relevant and cool projects on your GitLab instance. With this release, a new filter “Most stars” provides an incredible useful filter to show projects most starred on your instance.
Thank you for this contribution, Jacopo Beschi!
Download two-factor recovery codes
Two-factor authentication is a de facto standard for signing up for any relevant web-based application. At GitLab we understand and take this seriously. Whenever you set up a two-factor authentication initially, we provide limited recovery codes that allow you to regain access to your account as a fallback.
With this release, we now support download of recovery codes as a text file using the new “Download codes” button.
Thank you for this contribution, Luke Picciau!
Add support for interactive web terminal to Docker executor
The interactive web terminals feature has been expanded to be compatible with Docker executors as well. For now, the Docker session is closed as soon as the script exits, but we are aiming to further improve this behavior by resolving #3605 in our next release.
Allow pipelines to schedule delayed jobs
It is now possible to set a job to start after a delay via the when keyword in .gitlab-ci.yml. The timer starts ticking when the job would have otherwise started, giving you control to implement tasks that need to wait for a period of time to occur - for example, when implementing timed incremental rollouts, or any other delays needed after performing some other action.
Add manual entries for License Management
License Management policy allows developers to define if they want to approve or blacklist a specific license for their project. This can be done as soon as a new license is introduced, directly in the merge request page. But sometimes project maintainers want to populate the list beforehand, so that developers already know if their changes are aligned with the policy.
In GitLab 11.4, we introduce the ability to add manual entries for License Management. Project maintainers can prefill the policy in the Settings > CI/CD > License Management page by choosing from a set of common licenses, or add a custom entry to that list.
Git protocol v2
Developers fetch refs many times a day to check if the current branch is behind the remote branch. Git protocol v2 is a major update to Git’s wire protocol which defines how clones, fetches, and pushes are communicated between the client (your computer) and the server (GitLab). The new wire protocol improves the performance of fetch commands and enables future protocol improvements.
Previously, all responses to fetch commands included a list of all references in the repository. For example, fetching updates for a single branch (e.g. git fetch origin master) would also retrieve a complete list of all references. In the case of large projects, this could be over 100,000 refs and 10s of megabytes of data.
Git protocol v2 is supported from Git v2.18.0 and is opt-in. To enable globally run git config --global protocol.version 2. Git protocol v2 over SSH is not yet enabled on GitLab.com and must be enabled manually.
Prometheus 2.0 upgrade for Omnibus GitLab
Omnibus GitLab comes out of the box with Prometheus, allowing easy observability of deployed instances. The Prometheus team has released a major new version, the 2.x series, which offers a number of improvements. These include improved performance and a more efficient time-series database format. Unfortunately because of the architectural changes to the database, it is not backwards compatible with the old 1.x format.
With GitLab 11.4, Prometheus 2.4.2 is now available in the Omnibus package so users can take advantage of its benefits.
- New installations of 11.4 and above will start with Prometheus 2.
- Existing installations will not be automatically upgraded. We have added a new command,
gitlab-ctl prometheus-upgrade, which can be utilized to upgrade Prometheus and optionally migrate data. Prometheus will be stopped during data migration. - GitLab 12.0 will automatically upgrade to Prometheus 2.0. With the automatic upgrade, Prometheus 1.0 data will not be migrated.
For more information on upgrading Prometheus to 2.4.2, please review our update documentation.
Geo improvements for SSH Git commands proxy to primary node
Making Geo as easy to use as possible is one of our constant goals to support widely distributed teams using GitLab. In 11.3 we added initial support for proxying SSH git push from secondary nodes to primary nodes.
With this release, we further improve the performance and usability of this feature, allowing to clone and push to projects in a Geo scenario without having to maintain multiple configurations or update the remote URL manually.
Omnibus improvements
redis has been updated to 3.2.12, which is a critical security update that fixes multiple vulnerabilities. After upgrading to 11.4, run gitlab-ctl restart redis to ensure the new version is running.- GitLab 11.4 includes Mattermost 5.3, an open source Slack-alternative whose newest release includes enhanced search on desktop and mobile, plus much more. It includes security updates and upgrading is recommended.
git has been updated to 2.18.1, and libpng to 1.6.35.gnupg has been updated to 2.2.10, gpgme to 1.10.0, libgcrypt to 1.8.3, npth to 1.6, libgpg-error to 1.32, and libassuan to 2.5.1.- Certificates in the
trusted_certs directory are now set to 0644 permissions instead of 0755.
