11.3
Sep 22, 2018 - Daniel Gruesso   Daniel Gruesso

GitLab 11.3 Release

GitLab 11.3 released with Maven Repository and Protected Environments

GitLab 11.3 released with Maven Repository, Code Owners, Protected Environments, Epic Forecasting, and much more!

With our shipment today of GitLab 11.3, we are excited to announce support for Maven repositories, Code Owners, Protected Environments, and epic forecasting. These features help automate controls around environments and code while providing further efficiencies for Java developers.

Maven Repository

We have expanded our support for Java projects and developers by building Maven repositories directly into GitLab. This provides Java developers with a secure, standardized way to share version control in Maven libraries and save time by reusing these libraries across projects. This feature is available with GitLab Premium.

Code Owners and Protected Environments

GitLab Starter now supports the assignment of Code Owners to files to indicate the appropriate team members responsible for the code. This feature prepares us for futures releases that will enforce internal controls at the code level.

Available in GitLab Premium, operators can also use Protected Environments to set permissions determining who can deploy code to production environments. This significantly reduces the risk of the wrong person committing something they shouldn’t and increases overall security of the environment.

Epic forecasting

A new Portfolio Management feature in GitLab Ultimate can automatically forecast an epic's start and end dates based on the milestone dates of its issues. With this enhancement, portfolio managers will be able to compare their planned start and end dates against the work that is scheduled through milestones, gaining visibility into potential slippage in epic delivery. This will enable faster, better decisions on what can be delivered and when plans need to be adjusted.

Everyone can contribute

Many of these improvements were contributed by the greater GitLab community. We look forward to your feedback and improvements on these great new features. Together, we make an awesome team! 🏆

Let us know what you think in the comments below. What are you looking forward to in this release? What can we continue to improve on?

Join us for an upcoming event Watch the 11.3 Release Radar webcast

GitLab MVP badge

MVP This month's Most Valuable Person (MVP) is awarded to George Tsiolis

George added a very popular and highly requested feature that allows users to include private contributions on their own profile page.

Thank you, George, for your ongoing contributions to make GitLab even better! You’ll receive a brand new swag pack soon!

11.3 Key improvements released in GitLab 11.3

Maven repository

Maven repository

For any development organization, having an easy and secure way to manage dependencies is critical. Package management tools, such as Maven for Java developers, provide a standardized way to share and version control these libraries across projects.

In GitLab 11.3, we are proud to offer Maven repositories built directly into GitLab. Developers of lower-level services can now publish their packaged libraries to their project’s Maven repository. They can then share a simple XML snippet with other teams looking to utilize that library, and Maven and GitLab will do the rest.

Check out a sample project which builds and pushes to the GitLab Maven repository, and see how easy it is!

Maven repository
Documentation Issue

Interactive web terminals for Shell and Kubernetes Runners

Interactive web terminals for Shell and Kubernetes Runners

CI/CD jobs are executed by runners based on the configuration provided by users in their pipeline definition. But this execution is not interactive and, if it fails, users cannot dig into details to spot the possible source of the problem. Interactive web terminals bring the capability to connect to a running or completed job and manually run commands to better understand what’s happening in the system.

Documentation Issue
Interactive web terminals for Shell and Kubernetes Runners

Improve includes in .gitlab-ci.yml for reusing scripts

Improve includes in .gitlab-ci.yml for reusing scripts

Reusing CI/CD process code is a great practice to help ensure consistency in software delivery, and minimizes the amount of per-job scripting that’s needed to write and maintain. We now offer a flexible, powerful approach for code reuse in templates using YAML extends keywords.

Documentation Issue
Improve includes in <code>.gitlab-ci.yml</code> for reusing scripts

Include private contributions in user contribution graph

Include private contributions in user contribution graph

At GitLab, we love open source! But sometimes you want to work on a private project you don’t want to share (yet), or you are constrained for confidentiality reasons. In any case, GitLab has got you covered.

With this release, we are introducing the option to include private contributions in your profile’s contribution graph. Contributions to private projects are now displayed in the contribution graph and contributions of this day if you enable this setting for your profile. This way, your active work on private GitLab projects is represented accurately, without giving away any private details.

Thank you George Tsiolis for your contribution!

Documentation Issue
Include private contributions in user contribution graph

Redesigned project overview

Redesigned project overview

Iterating on our user interface is a constant focus for improving our product.

With GitLab 11.3, we are updating the UI of the project overview page to allow for a better experience when exploring projects. Besides improving the overall information structure of this page, we are left-aligning the top header section and optimizing the vertical spacing, so you can get a quicker overview about the project and its content.

Documentation Issue
Redesigned project overview

Protected Environments

Protected Environments

Operators are often responsible for the sensitive task of protecting the environments we deploy code to on a daily basis. This task becomes particularly important when deploying code to a production environment.

With Protected Environments, operators obtain full control around which person, group, or account is allowed to deploy to a given environment, allowing further protection and safety of sensitive environments.

Documentation Issue
Protected Environments

Code Owners

Code Owners

Code review is an essential practice of every successful project, but who should review the changes is not always clear. GitLab now supports assigning code owners to files to indicate the team members responsible for code in your project.

Code owners are assigned using a file named CODEOWNERS, a format similar to gitattributes, and are listed below the commit details when viewing a file in GitLab.

In upcoming releases, Code Owners will be integrated into the merge request workflow to suggest approvers, assign approvers, and enforce code owners.

Documentation Issue
Code Owners

Epic forecasting with integrated milestone dates

Epic forecasting with integrated milestone dates

Prior to this release, you could set fixed values for the planned start date and the planned end date of an epic. This is useful for high-level planning of epics, and tracking them over time. However, as issues are attached to the epic, and the issues are scheduled for work with actual milestones, it would be useful to have the epic dates reflect those milestones.

With this release, you can easily switch from the fixed value for either of the dates, to a dynamic value called From milestones. For the planned start date, this dynamic value will take on the earliest start date of all milestones assigned to the epic’s attached issues. This is truly dynamic in that it will change if issues are added or removed, if milestones are assigned or unassigned (to those issues), or if the start dates are changed for those milestones. The dynamic version of the epic’s planned end date is analogous.

This feature is useful if you want to seamlessly transition from high-level, top-down planning to micro-level, bottom-up planning. See more in a blog post on the Epics roadmap that we published about this a few weeks back.

Documentation Issue
Epic forecasting with integrated milestone dates

11.3 Other improvements in GitLab 11.3

New epic event as custom notification

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.

New epic event as custom notification
Documentation Issue

Allow self-approval of merge requests

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.

Documentation Issue

Custom file templates for self-managed instances

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.

Documentation Issue

Define project name when creating a new project

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.

Define project name when creating a new project
Documentation Issue

SAST support for Groovy

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.

Documentation Issue

Alerts for library metrics

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.

Alerts for library metrics
Documentation Issue

Geo improvements

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.

Documentation Issue Board

Gitaly v1.0

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.

Documentation Issue

GitLab Runner 11.3

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.

Documentation

Omnibus improvements

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.
Documentation

Quick action to add issue to epic (from issues)

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.

Quick action to add issue to epic (from issues)
Documentation Issue

Display repository languages on project overview

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.

Display repository languages on project overview
Documentation Issue

File templates in the Web IDE

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.

File templates in the Web IDE
Documentation Issue

Store Wiki uploads in the Wiki repository

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.

Documentation Issue

Filter webhook push events by branch

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!

Filter webhook push events by branch
Documentation Issue

Auto DevOps enabled by default

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.

Auto DevOps enabled by default
Documentation Issue

Automatically disable Auto DevOps for project upon first pipeline failure

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.

Automatically disable Auto DevOps for project upon first pipeline failure
Documentation Issue

List of open source software components used by GitLab now available online

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

Performance improvements

Some of the more noteworthy performance improvements in GitLab 11.3 include:

Performance improvements

Deprecations Deprecations

Support for Docker Versions in GitLab Runner

Support for Docker Versions in GitLab Runner

With GitLab 11.4 (October 22, 2018), support for Docker versions before 1.12 (API version 1.24) will be deprecated in line with Docker’s latest version recommendation guidance. Beyond the 11.4 release these older versions will no longer be officially supported and could stop working at any time.

Planned removal date: October 22, 2018

Removals and breaking changes Removals and breaking changes

The complete list of all removed features can be viewed in the GitLab documentation. To be notified of upcoming breaking changes, subscribe to our Breaking Changes RSS feed.

Upgrade barometer Upgrade barometer

To upgrade to GitLab 11.3 from the latest 11.2 version, no downtime is required. To upgrade without downtime, please consult the documentation on downtimeless upgrades.

For this release we have migrations, post-deploy migrations, and, to help with the larger migrations, we have introduced background migrations.

GitLab.com migrations took approximately nine minutes and post-deploy migrations amounted for a total of around 15 minutes. Background migrations on the other hand are Sidekiq jobs that will run synchronously, for this release we expect the migrations to take rougly 90 days to complete on GitLab.com. The migration modifies all build-artifact information to a new format.

GitLab Geo users, please consult the documentation on upgrading Geo.

Changelog Changelog

Please check out the changelog to see all the named changes:

Installing Installing

If you are setting up a new GitLab installation please see the download GitLab page.

Updating Updating

Check out our update page.

Questions? Questions?

We'd love to hear your thoughts! Visit the GitLab Forum and let us know if you have questions about the release.

GitLab Subscription Plans GitLab Subscription Plans

  • Free

    Free-forever features for individual users

  • Premium

    Enhance team productivity and coordination

  • Ultimate

    Organization wide security, compliance, and planning

Try all GitLab features - free for 30 days

Cover image licensed under Unsplash

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

Take GitLab for a spin

See what your team could do with The DevSecOps Platform.

Get free trial

Have a question? We're here to help.

Talk to an expert
Edit this page View source