With this release, we continue to iterate on our portfolio management feature of Epics. Just like with issues, you can now comment on epics, and even start standalone, threaded discussions in an epic, just like in issues and merge requests. This allows you to have a conversation with your teammates, in an epic directly, at a higher abstraction level, before necessarily drilling down in an issue, or even creating one.
This new feature is also supported in the API.
Email notifications and todos are not yet supported in epics, and we are working on them right now.
Read through the documentation on Epics
Custom additional text for all emails
Often, organizations need to add a disclaimer or other related text to all email communications, for various operational or compliance requirements.
With this release, we’ve added this exact feature. GitLab admins can now go into email settings and paste in any custom text. That text will then appear at the bottom of all emails sent by GitLab.
Read through the documentation on custom text for emails
Subgroup issues in Group Issue Board
Group issue boards are a powerful feature to help you manage issues across multiple projects across a single group, all in one interface. This is helpful for teams where their work might come from multiple different code repositories (and thus GitLab projects).
Prior to this release, the issues in a group issue board only came from immediate child projects of that one group. With this release, all issues in projects in all subgroups of the current group also appear in that one group board. So if your work is structured in a group and project hierarchy with multiple levels reflecting your organization or software product, then this update will extend that hierarchy to the group issue board now, giving you more fine-grained control.
Read through the documentation on Issue Boards
Assigning and filtering by subgroup labels
Subgrouping is a powerful feature in GitLab, and we want to extend that functionality to how labels are applied in GitLab. With this release, we’ve made it extremely flexible to apply group labels to issues and merge requests at various subgroup levels.
In particular, for a given issue or merge request, you can now apply any group label from that object’s ancestor groups. This flexibility means that you can create a label at a given group level, and all objects in its subgroups will be able to use it.
Since in group issue lists and group merge request lists, you can already see objects belonging to subgroups, we’ve now also made it possible to filter on those lists by group labels that belong to both ancestor and descendant groups of the given group, since all those objects can have those labels now. In other words, GitLab gives you the power and flexibility to filter by any possible label assignable to those objects.
This filtering capability is also possible in group issue boards for both the filter bar and the board config.
Read through the documentation on Labels
Project Badges
Many projects use badges, such as the GitLab CI/CD and shields.io to reflect status of build and code quality. Typically these are added to the project README.
Now badges are a first-class citizen and can be displayed prominently below the project description, and can be templated at the group level too.
Read through the documentation on Project Badges
Protected branch unprotect permissions
Protected branches allow push and merge permissions to be restricted by branch, like preventing pushes directly to master, but any Master can bypass these rules by unprotecting the branch. The new unprotect restriction can be used to limit which users, groups and roles are allowed to unprotect a branch.
Unprotect restrictions can only be set using the API in 10.7, but will be available in the interface in an upcoming release. The admin access level (60) may be removed in a future release, as we are currently evaluating restrictions to the Owner role as an alternative.
Read through the documentation on Branch Protection
Issue weight in Issue Board card
You can now view the weight in an issue board card. Previously, when using an issue board, to see the weight of an issue, you’d have to click on the issue, and see the weight in the sidebar that slides in. With this change, you can now see it in the board card itself. This makes it much more easy to quickly scan a board and see the weights of issues, giving you a rough sense of the work required in a given list of issues, which is helpful in methodologies such as Agile.
Read through the documentation on Issue Boards
GitLab Plugins
Being open source means GitLab can always be improved by anyone, but not all customers want to upstream their changes, or they may want to iterate on them privately first. Up to now, this was only possible by running a fork of GitLab, which is hard to keep up to date.
Plugins allow you to respond to GitLab system hooks with a script stored on the GitLab server, so you can more easily extend GitLab to meet your needs, like automatically configuring custom protected branch rules whenever a new project is created.
Read through the documentation on Plugins
HTTP(s) Git protocol always available for CI/CD jobs
With GitLab you can use either SSH or HTTP(s) to access your repositories. Sometimes GitLab administrators prefer to block HTTP(s) access for security reasons. For example, blocking HTTP(s) prevents users from disclosing their credentials due to an insecure client setup. However, blocking HTTP(S) also stopped GitLab Runner from cloning the repository, making CI/CD not work as expected.
Starting with GitLab 10.7, the HTTP(s) protocol will be allowed for clone/fetch requests coming from GitLab Runner, even if the same access is explicitly forbidden for users. This is not susceptible to the same type of inseucre client vulnerability because GitLab Runner always uses OTP tokens that cannot be leveraged to perform attacks.
Read through the documentation on visibility and access controls
Support for JSON Web Token OmniAuth
GitLab uses OmniAuth to allow users to sign into GitLab using popular services like Twitter and Google, as well as standard authentication solutions like OAuth2. In Gitlab 10.7, support for JSON Web Token (JWT) OmniAuth has been added.
JSON Web Token is a compact and self-contained way to securely transmit information, and is commonly used for authentication between services.
Read through the documentation on JWT OmniAuth provider
Automatic background verification of Geo replicas
Automatic background verification of Geo replicas will now occur when Geo is enabled, to make sure that replicas remain consistent with the primary. This is important when using Geo for Disaster Recovery so that you can confidently fail over to a secondary, knowing that it is a a complete replica of your primary GitLab instance.
GitLab calculates a checksum for each Git repository using heads and tags and verifies that the checksum from the primary matches the checksum on each secondary. Verification will be expanded in upcoming releases to also include uploads and keep-around refs.
Read through the documentation on Geo background verification
Group project creation in Starter
As part of providing additional flexibility around our permission model, this will allow group or server admins to set an option that will give users with Developer role the ability to create projects.
This feature was previously available in GitLab Premium only.
Read through the documentation on Groups
Project exports include LFS objects
Project exports allow you to move projects between GitLab instances conveniently, including issues, merge requests, labels, wikis and uploads. Project exports now include LFS objects so that repositories with LFS objects can also be transferred using project exports.
Read through the documentation on project exports
Dependency Scanning is now an independent feature
Before this release, security checks on external dependencies and libraries used by your application were done along with SAST. Even if they are related, we think that they should be clearly identified as two separate features.
GitLab 10.7 introduces Dependency Scanning as a first-class citizen in the Security reports, giving you information about vulnerable libraries that should be updated. Results will be available both in the merge request and in the pipeline view.
Read through the documentation on Dependency Scanning
Runner-specific job timeout
GitLab currently defines at the project level how long a CI/CD job can run. If a job execution exceeds this duration, it is automatically stopped and reported as failed.
GitLab 10.7 adds a new timeout setting on the runner itself, which applies to all jobs it runs. If this value is less than the project-level setting, it will override it. This is particularly helpful for shared runners, in order to prevent potential abuse with a project that has set long timeouts.
Read through the documentation on runner-specific job timeout
Easily get failure reasons for CI/CD jobs
When a CI/CD job fails, users normally want to check what happened and commit a fix to make it succeed as expected. Before this release, they had to go into the job details and look at the logs.
To make the debugging easier and faster, GitLab 10.7 introduces the failure reason as part of the status badges, make it accessible on mouseover.
Read through the documentation on failure reasons for CI/CD jobs
Improvements to restoring GitLab backups
GitLab 10.7 now includes support for restoring to custom nested directories. For example if your registry was located at /var/mypath/gitlab/registry, the restore will now succeed. Previously the task would try to rename the existing directory to <name>.<timestamp>, but it would not have permission. Now it will create a tmp folder in the backup directory, and move any existing files there prior to restoring the backup.
Read through the documentation on backup and restore
GitLab Pages automatic HTTPS redirect
GitLab Pages can provide static websites via HTTP or HTTPS protocols. HTTPS is normally preferred since it encrypts all the traffic, protecting the content while it is transferred over the net.
In the case that both are available, in GitLab 10.7 users can force their projects to redirect HTTP requests on the related HTTPS url to improve security and guarantee no data is transferred in clear text.
Read through the documentation on GitLab Pages automatic HTTPS redirect
Improvements to the environment metrics dashboard
Summary statistics are now available on the environment metrics dashboard, displaying the average and maximum values of each series within the timespan. For example it is now possible to quickly see the average response time for the past eight hours, to understand the experience most users are seeing.
Total Pod CPU and Memory consumption are now also displayed, providing insight into the resource usage of a particular environment in the cluster.
Read through the documentation on monitoring environments
GitLab Runner 10.7
We’re also releasing GitLab Runner 10.7 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.
Read through the documentation on GitLab Runner
Omnibus improvements
- GitLab Mattermost 4.8.1 includes several platform improvements, including an iOS endpoint that enables users to upload files larger than 20MB, plus much more.
- The default
ssl_ciphers list for NGINX has been updated, excluding ECDHE-RSA-DES-CBC3-SHA and DES-CBC3-SHA to address Sweet32. - redis_exporter has been updated to 0.17.1.
Read through the documentation on Omnibus GitLab
Custom additional text for all emails
Often, organizations need to add a disclaimer or other related text to all email communications, for various operational or compliance requirements.
With this release, we’ve added this exact feature. GitLab admins can now go into email settings and paste in any custom text. That text will then appear at the bottom of all emails sent by GitLab.
Read through the documentation on custom text for emails
Assigning and filtering by subgroup labels
Subgrouping is a powerful feature in GitLab, and we want to extend that functionality to how labels are applied in GitLab. With this release, we’ve made it extremely flexible to apply group labels to issues and merge requests at various subgroup levels.
In particular, for a given issue or merge request, you can now apply any group label from that object’s ancestor groups. This flexibility means that you can create a label at a given group level, and all objects in its subgroups will be able to use it.
Since in group issue lists and group merge request lists, you can already see objects belonging to subgroups, we’ve now also made it possible to filter on those lists by group labels that belong to both ancestor and descendant groups of the given group, since all those objects can have those labels now. In other words, GitLab gives you the power and flexibility to filter by any possible label assignable to those objects.
This filtering capability is also possible in group issue boards for both the filter bar and the board config.
Read through the documentation on Labels
Protected branch unprotect permissions
Protected branches allow push and merge permissions to be restricted by branch, like preventing pushes directly to master, but any Master can bypass these rules by unprotecting the branch. The new unprotect restriction can be used to limit which users, groups and roles are allowed to unprotect a branch.
Unprotect restrictions can only be set using the API in 10.7, but will be available in the interface in an upcoming release. The admin access level (60) may be removed in a future release, as we are currently evaluating restrictions to the Owner role as an alternative.
Read through the documentation on Branch Protection
GitLab Plugins
Being open source means GitLab can always be improved by anyone, but not all customers want to upstream their changes, or they may want to iterate on them privately first. Up to now, this was only possible by running a fork of GitLab, which is hard to keep up to date.
Plugins allow you to respond to GitLab system hooks with a script stored on the GitLab server, so you can more easily extend GitLab to meet your needs, like automatically configuring custom protected branch rules whenever a new project is created.
Read through the documentation on Plugins
Support for JSON Web Token OmniAuth
GitLab uses OmniAuth to allow users to sign into GitLab using popular services like Twitter and Google, as well as standard authentication solutions like OAuth2. In Gitlab 10.7, support for JSON Web Token (JWT) OmniAuth has been added.
JSON Web Token is a compact and self-contained way to securely transmit information, and is commonly used for authentication between services.
Read through the documentation on JWT OmniAuth provider
Group project creation in Starter
As part of providing additional flexibility around our permission model, this will allow group or server admins to set an option that will give users with Developer role the ability to create projects.
This feature was previously available in GitLab Premium only.
Read through the documentation on Groups
Dependency Scanning is now an independent feature
Before this release, security checks on external dependencies and libraries used by your application were done along with SAST. Even if they are related, we think that they should be clearly identified as two separate features.
GitLab 10.7 introduces Dependency Scanning as a first-class citizen in the Security reports, giving you information about vulnerable libraries that should be updated. Results will be available both in the merge request and in the pipeline view.
Read through the documentation on Dependency Scanning
Easily get failure reasons for CI/CD jobs
When a CI/CD job fails, users normally want to check what happened and commit a fix to make it succeed as expected. Before this release, they had to go into the job details and look at the logs.
To make the debugging easier and faster, GitLab 10.7 introduces the failure reason as part of the status badges, make it accessible on mouseover.
Read through the documentation on failure reasons for CI/CD jobs
Improvements to restoring GitLab backups
GitLab 10.7 now includes support for restoring to custom nested directories. For example if your registry was located at /var/mypath/gitlab/registry, the restore will now succeed. Previously the task would try to rename the existing directory to <name>.<timestamp>, but it would not have permission. Now it will create a tmp folder in the backup directory, and move any existing files there prior to restoring the backup.
Read through the documentation on backup and restore
Improvements to the environment metrics dashboard
Summary statistics are now available on the environment metrics dashboard, displaying the average and maximum values of each series within the timespan. For example it is now possible to quickly see the average response time for the past eight hours, to understand the experience most users are seeing.
Total Pod CPU and Memory consumption are now also displayed, providing insight into the resource usage of a particular environment in the cluster.
Read through the documentation on monitoring environments
Omnibus improvements
- GitLab Mattermost 4.8.1 includes several platform improvements, including an iOS endpoint that enables users to upload files larger than 20MB, plus much more.
- The default
ssl_ciphers list for NGINX has been updated, excluding ECDHE-RSA-DES-CBC3-SHA and DES-CBC3-SHA to address Sweet32. - redis_exporter has been updated to 0.17.1.
Read through the documentation on Omnibus GitLab
