Comments in epics
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.
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.
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.
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.
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.
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.
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.
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.
Ubuntu 18.04 Bionic support
Packages are now available for
Ubuntu 18.04 Bionic,
which is being released on April 26.
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.
Cloud native GitLab chart available for Core (alpha)
With the introduction of Object Storage support to Core,
the alpha cloud native GitLab chart
can now be used without a license. This chart features a more cloud native
architecture, with a container for each component of GitLab and no requirement
for shared storage. These changes will result in increased resilience,
scalability, and performance of GitLab on Kubernetes.
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.
Performance improvements
Some of the more noteworthy performance improvements in GitLab 10.7
include:
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.
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.
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.
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.
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.
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.
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.
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.
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.
Automatic renewal of GitLab Let’s Encrypt certificate
In GitLab 10.5, we made it easy to enable HTTPS for your GitLab instance
by integrating with Let’s Encrypt.
With GitLab 10.7, we are making it even easier by no longer requiring
it to be explicitly enabled as well as automating the renewal process.
All you need to do to enable HTTPS now is set your external_url to
start with https://, and that’s it!
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.
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.
We want to hear from you
Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.
Share your feedback