New epic event as custom notification
In a previous release, we provided email notifications for new epics,
for users who have configured their group-level notifications to the
Watch level. With this release, we are adding more customization.
You can now configure this event trigger on or off using the Custom notification
level, along with other event triggers.
Allow self-approval of merge requests
The user who creates a merge request may not be the author of the
changes, and other users may add additional changes to the merge
request after it is opened. Maintainers can now allow self-approval
of merge requests from the project settings.
Previously, the user who opened the merge request was assumed to
implicitly approve the merge request and was therefore excluded from
approving the merge request. There are many situations where this is
not true. Allowing self-approval removes this assumption.
Custom file templates for self-managed instances
File templates for LICENSE, .gitignore, Dockerfile and
.gitlab-ci.yml files make it easy to add these common files to
projects. Custom file templates can now be added to self-managed GitLab
instances by selecting an instance-wide template repository which
contains your templates.
Custom templates are useful when the templates provided by GitLab are
too generic, for example a custom license that should be used for every
project in the company, or a complex Dockerfile that should be used
for every microservice.
Thank you Daniel Barker for
contributing
custom license templates.
Define project name when creating a new project
To add a project name to your newly created GitLab project, you previously had to go into the
project settings and overwrite the project slug with a proper name.
With GitLab 11.3, we are adding the project name field to the “Create project” form. In addition,
the project slug is now automatically generated from the project name, while still allowing
you to adjust this field. This improvement makes the process of creating a new project faster
and more straightforward.
SAST support for Groovy
Static Application Security Testing is responsible for spotting vulnerabilities in your
source code as soon as it is committed to the repository, looking for known patterns
and common errors that may lead to security flaws in the final application.
That’s why each different language needs specific support.
With GitLab 11.3, we introduce Groovy
in the list of languages supported by GitLab SAST. Projects using this language are
now automatically detected and you don’t need to change anything to your code or your
pipeline definition to enable this feature. Auto DevOps is also supporting it as part
of its default configuration.
Alerts for library metrics
In GitLab 11.2, we added the ability to set alerts for custom metrics, which allowed developers to be notified
in the event of any issues with their applications.
With GitLab 11.3, we have now extended support for alerts to all metrics, including the metrics that
are provided by default with our library metrics.
Geo improvements
We continually focus on improving our Geo feature for distributed teams. Some of the noteworthy improvements in GitLab 11.3 include:
You can also read about how we built GitLab Geo.
Gitaly v1.0
Git access for regular usage of GitLab can now occur entirely through
Gitaly, GitLab’s gRPC service to access Git. This means it is possible
to run Gitaly on its own server without NFS when all optional feature
flags are enabled.
In the upcoming Gitaly v1.1
release all feature flags will be enabled by default, and the last
few remaining features will use Gitaly, removing the need for NFS.
Read our blog post about
the road to Gitaly v1.0.
GitLab Runner 11.3
We’re also releasing GitLab Runner 11.3 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:
A list of all changes can be found in GitLab Runner’s CHANGELOG.
Omnibus improvements
- GitLab 11.3 includes Mattermost 5.2,
an open source Slack-alternative which includes an
upgraded plugin system, ability to search archived channels, Romanian language
support, and much more. Since it includes
security updates, upgrading is recommended.
gitlab-elasticsearch-indexer has been updated to 0.2.2.omnibus-ctl has been updated to 0.6.0.- The Redis tcp_backlog and
HZ
settings are now configurable, as well as
max_concurrency
in sidekiq_cluster.
- The default maximum memory Sidekiq can use is now 2GB.
- SSL compression has been disabled by default for
gitlab-psql and gitlab-geo-psql.
Quick action to add issue to epic (from issues)
Adding an issue to an epic (or removing an already attached issue) is easily
done from the epic page itself. This is useful for when you are already
working in an epic.
But sometimes you are working in an issue, and know that you want to attach
it to an existing epic that you know about. You can now do so with a simple quick
action on the issue page by pasting in the epic URL. In a future release,
you’ll even be able to search for the epic in the quick action command via
autocomplete.
Additionally, another issue quick action will allow you to remove it from
an already attached epic.
Display repository languages on project overview
The code languages of which a repository consists is relevant information when exploring GitLab
projects.
With this release, we are adding a code languages bar to the project overview, showing all
relevant languages the repository consists of, including their relative quantity.
File templates in the Web IDE
File templates for LICENSE, .gitignore, Dockerfile and
.gitlab-ci.yml make it easy to add these common files to projects,
and can now be used in the Web IDE. File templates in the Web IDE makes
it easier to start a new project in the Web IDE and keep these
important files up to date.
Store Wiki uploads in the Wiki repository
Images uploaded to the wiki through the wiki editor are now stored in
the Git repository. This means images will now be display when
previewing a wiki locally using Gollum.
Previously, images were stored in the project uploads directory with
attachments uploaded to issues and merge requests. This prevented wikis
from being previewed locally or being migrated to a different Git
repository.
Filter webhook push events by branch
Webhooks for push events make it easy to automatically notify external
services of new commits, but all branches are rarely of equal
importance. Push events can now be filtered by branch so that
external services are only notified about the changes that matter to
you.
Previously webhooks could not be filtered by GitLab, and most external
systems do not have a feature filter incoming events. This meant it was
not possible to integrate these services directly with GitLab if you
only wanted a subset of push events to be used by the external service.
Thank you Duana Saskia for your
contribution!
Auto DevOps enabled by default
Auto DevOps was made generally available in GitLab’s 11.0 release and while it has
had great adoption, we want all GitLab users to take advantage of its great features.
From Auto Build to Auto Monitoring, Auto DevOps brings valuable benefits out of the box.
Starting with GitLab 11.3, Auto DevOps will be enabled by default on both GitLab.com and on
self-managed instances, so that every project can take advantage of its features.
Read through the documentation on enabling/disabling Auto DevOps if you wish to disable it for your project or for an entire instance.
Automatically disable Auto DevOps for project upon first pipeline failure
At GitLab, one of our product values is to default to on.
When we introduce a new configurable feature we know to be of great value, we will
default to ON so that everyone can benefit from it. While Auto DevOps supports
projects using the most popular programming languages, there may be some specialized
projects for which additional configuration is required.
Because we want to ensure we will not be running Auto DevOps pipelines for projects
that are not supported, we will disable Auto DevOps automatically if one of its pipelines fails.
GitLab will notify the project owner of this attempt so they can make the necessary
configuration changes to work with Auto DevOps if desired. Once the necessary changes are made,
project owners can re-enable Auto DevOps.
List of open source software components used by GitLab now available online
Starting with GitLab 11.3, we are making the list of open source software used by
GitLab more easily available. Prior to this release, it was available in each of our
Linux packages, but that required downloading and extracting the contents.
We are now publishing this content online, so it is easier to access and link to.
The list is available for GitLab CE and GitLab EE.
Performance improvements
Some of the more noteworthy performance improvements in GitLab 11.3 include:
