Feb 22, 2018 - Fabio Busatto  

GitLab 10.5 released with Let's Encrypt integration, Gemnasium dependency checks, and CI/CD external files

GitLab 10.5 released with Let's Encrypt integration, CI/CD external files, Gemnasium dependency checks, External Policy Classification Control, and much more!

In this month’s release of GitLab 10.5 we’ve added capabilities to encrypt GitLab traffic easily, improve application security, scaling CI/CD management, and so much more.

Secure GitLab deployments in less time

HTTPS is a pillar of internet security and a must-have if your GitLab instance is exposed to the public internet. It provides two key benefits. First, traffic is encrypted to and from the server, protecting credentials and other sensitive data from potential eavesdropping. Second, it allows users to verify the site identity. Without a verified identity it's possible for users to log into the wrong site. These capabilities are particularly important for mobile and remote users, who often use public unsecured Wi-Fi increasing the risk of snooping or interacting with a malicious site.

Although HTTPS provides great security, setting up HTTPS and requesting certificates can be a hassle involving credit cards and key management.

Let’s Encrypt is a free, automated, and open certificate authority. With GitLab 10.5 we’ve added Let’s Encrypt integration, allowing you to enable instant SSL certificates with a single option. Enabling Let’s Encrypt on your GitLab instance ensures traffic to your GitLab instance is encrypted and the identity of your site is verified. The Let’s Encrypt integration is available on both paid and open source GitLab.

Scale your pipeline management

Today, we’re releasing a simple feature with powerful implications.

Running DevOps in an enterprise environment comes with some unique challenges. For many of our largest customers, the DevOps team is responsible for providing CI/CD pipelines to a large number of development teams throughout the organization. Previously, this was a painful process to manage. There wasn’t a scalable way to distribute reusable pipeline configuration which meant code needed to be manually copied between multiple .gitlab-ci.yml files in multiple projects. This was a labor-intensive and error-prone process. Additionally, it didn't provide adequate controls to ensure testing and deployment is consistently enforced for each repo.

Starting with 10.5, you can now include external files in CI/CD pipeline definition. Included files can be either local (contained in the same repo) or remote (accessible via HTTP/HTTPS). Including local files allows a large and complex .gitlab-ci.yml to be broken up in to modular chunks that are easier to maintain. Remote files allow these modular chunks to be distributed across thousands (or potentially millions) of repositories. Now there’s a simple, consistent, and maintainable way to distribute pipeline configuration.

Better security testing with Gemnasium

Less than a month ago, GitLab acquired Gemnasium. As promised, we haven’t wasted any time in bringing Gemnasium’s advanced dependency-checking functionality to GitLab users. Often, when companies make acquisitions, they tend to create bolt-on additions or package functionality as separate offerings. GitLab’s vision is to provide a single application architecture so that dev, QA, security, and ops can work concurrently off the same data in the same interface. In this spirit we’ve integrated Gemnasium’s technology seamlessly into GitLab CI/CD, supercharging security testing.

Thanks to advanced algorithms and a larger vulnerability database, GitLab now provides more complete results in JavaScript, Ruby, and Python. We’ve also added PHP and Java support so you have five languages total.

See all the features

This post highlights 26 enhancements (18 of which are available in open source GitLab!) For the full list of improvements see the changelog. Or read on to learn more about all of the key features shipped in 10.5!

Join us for an upcoming event

GitLab MVP badge

This month's Most Valuable Person (MVP) is Hiroyuki Sato

Hiroyuki has been contributing to GitLab from the early days, and this is the third time that his work is so appreciated that we want him as MVP (the first time was in 5.1!). In GitLab 10.5 he added the ability to see the merge request that introduced a specific commit. This helps to track previous changes, speeding up the development.

Thanks a lot Hiroyuki, you did it again! We know that the GitLab Hall of Fame page is the best prize ever, but we also sent Hiroyuki a handmade tanuki, GitLab socks, and a GitLab shirt!

Instant SSL with Let's Encrypt for GitLab

GitLab often contains some of the most sensitive information within an organization, their source code, and protecting that IP is important. Utilizing HTTPS to encrypt sensitive data like credentials, as well as validating the identity of a site, is a fundamental first step in securing any internet service.

In the past, enabling HTTPS for GitLab has been a multiple-step process. An organization would have to generate a certificate request, pay a Certificate Authority, copy the files to the GitLab server, and finally configure GitLab to use them.

With 10.5 we have made this process significantly easier, by integrating with Let’s Encrypt. If your instance is reachable on the internet via HTTP today, simply set letsencrypt['enable'] = true in gitlab.rb and reconfigure. That’s it, HTTPS will now be enabled for the main GitLab domain!

We will be enabling Let’s Encrypt by default as well as adding support for other GitLab features like the Registry, Pages, and Mattermost, in a future release.

Instant SSL with Let's Encrypt for GitLab

Learn more about Let's Encrypt integration

Include external files in CI/CD pipeline definition

GitLab CI/CD pipelines are defined in a YML definition file that is stored in the project’s repository. Many times you are using the same job definitions for many different projects, or just copying and pasting existing snippets from examples and documentation.

With GitLab 10.5 you can now import other files into your main configuration using the new include keyword. These files can be both local files on the same repository, or remote files that are publicly accessible via HTTP/HTTPS. Security checks and deployment configurations are common examples of jobs that can be reused and shared.

Read through the documentation on including external files

Include external files in CI/CD pipeline definition

Gemnasium dependency checks

GitLab recently acquired Gemnasium and since then we have worked together to integrate this awesome technology into our security testing features.

Thanks to the advanced detection and the database of existing vulnerabilities, with GitLab 10.5 you can now receive very accurate security reports for dependencies of your application for the following languages:

  • Ruby
  • Java (Maven)
  • Javascript (NPM)
  • Python
  • PHP

If you are already using Auto DevOps, you don’t need to change anything. If you copied the job definition to your pipeline, you can update it to support the latest features. See the example page for more information.

Read through the documentation on supported languages and tools for security checks

Gemnasium dependency checks

Track additional browser performance metrics

In GitLab 10.3, we added the ability to quickly determine the performance impact of merge request with Browser Performance Testing. With this release we are analyzing three additional metrics for changes: speed index, transfer size, and number of requests.

We have also added the capability to persist the full sitespeed.io report as an artifact, allowing developers and reviewers easy access to a trove of performance and debugging information. If you are using Auto DevOps, the report will be automatically saved for you.

Learn more about Browser Performance Testing

Track additional browser performance metrics

Git LFS 2 locking support

Git LFS 2.0.0 added file locking support to Git LFS. It is now supported by GitLab, allowing LFS files to be locked using the Git LFS client. Locked files are easily identified by the lock icon.

Support for locking any file or directory was added to GitLab Premium 8.9, allowing files to be locked through the GitLab interface. Git LFS locking has been integrated with GitLab file locking in GitLab Premium 10.5.

Learn more on how to use Git LFS

Git LFS 2 locking support

Other Improvements in GitLab 10.5

View Epics in roadmap

The first iteration of roadmaps is now available in GitLab. Roadmaps allow you to view multiple epics in the same group (and even epics in subgroups), all together in a time-based view. You can view when epics begin, and when they end together.

This helps users plan and track work across time, and also allows users to see how different work coincides with each other. For example, if you plan to launch a new feature in your product in the second quarter of 2018, and you want to have a marketing campaign to go along with it, you would create one epic for the product work, and another epic for the marketing work, and you would see them both together in the roadmap view, to ensure that they start and end according to your plans.

View Epics in roadmap

Read through the documentation on Roadmaps

Dynamic management of secret variables

Secret variables are useful to customize your CI/CD pipelines without exposing sensitive values to the world. Users with Master permissions can define them in the CI/CD > Settings menu, but the process allowed just one insertion at a time, making bulk definitions really hard.

In GitLab 10.5 we have a new dynamic management for adding secret variables, supporting multiple insertions at the same time and greatly improving the user experience.

Dynamic management of secret variables

Read through the documentation for secret variables

Instance level domain for Auto DevOps

Auto DevOps can automatically deploy your application to a Kubernetes cluster, but in order to access it you need to provide a domain name associated to the public IP address of the cluster.

With GitLab 10.5, you can now specify this domain at instance level, so it can be automatically used by any project that doesn’t override this value with a specific one, and share it across your entire organization.

Read through the documentation on Auto DevOps base domain

Transfer groups

Making it easier to structure groups and subgroups, you can now take an entire GitLab group and transfer it into another group.

Transfer groups

Read through the documentation on Groups

Deployed Ingresses now configured for Prometheus metrics

Deployed Ingresses are now configured for Prometheus metrics, enabling easy application monitoring for response metrics: latency, throughput, and error rate.

Learn more about deploying Ingress on Kubernetes

Approve additionally in Merge Requests

We’ve streamlined and simplified the logic of merge request approvals, making it even easier for users to configure and use approvals.

In particular, users can now approve a merge request even if the number of approvals have already been met. This makes it easier for approvers to give their approval signals, and they do not have to wait or consider other approvers when approving. It encourages more people to approve and participate in the overall code review process.

However, if your workflow is more restrictive, you can set the number of required approvals to exactly the eligible approvers you have selected.

Approvers can continue to remove their existing approval if they have already given one in the merge request.

Approve additionally in Merge Requests

Read through the documentation on Merge Request Approvals

View all issues of all subgroups on group issues page

You can now view all issues of all subgroups on the group issues page. This makes the group issues page more powerful when you have a nested tree structure of groups several levels deep, and you want to view all issues in that tree in one location. For example, this is useful for teams with microservices that may be spread across multiple projects and groups, or for teams that have a nested organization team structure.

The same change has been brought to the group merge requests page too.

View all issues of all subgroups on group issues page

Read through the documentation on Issues

Color chips in GitLab Flavored Markdown

GitLab Flavored Markdown (GFM) now supports color chips. That means anywhere you can enter GFM (such as issue and merge request descriptions and comments), you can type a color code, and GitLab will render a helpful color chip next to it. This is especially useful for designers and frontend engineers to collaborate on designs involving color details, within GitLab.

Thank you @thetonyrom and @raviolicode for the contribution!

Color chips in GitLab Flavored Markdown

Read through the documentation on GitLab Flavored Markdown

Push to create a project

Pushing a repository to an unused project name in your personal namespace now automatically creates a private project, so you can start prototyping your next project even faster!

Learn more on how to create projects

Single secondary Disaster Recovery is now Generally Available

Disaster Recovery uses Geo replication to allow quick failover to a different site with minimal effort in a disaster situation. Failover to a secondary in configurations with a single secondary is now GA.

Read through the documentation on Disaster Recovery.

Epics search and filter bar

In this release, we’ve added the GitLab search and filter bar to the Epics list page. It’s the same search and filter bar that exists throughout GitLab, for issues and merge requests. In this release, you are able to filter by epic author, and search epic titles and descriptions. Additionally, ordering functionality is also available, for ordering by when an epic was created, or last updated.

This brings the benefits of list organization that you already experience with issues and merge requests. You can easily manage and narrow down to the epics that you care about by applying the search and filtering. In the future, we will bring additional filters, most notably labels.

Epics search and filter bar

Read through the documentation on Epics

Persistent public projects deployments

Auto DevOps (Beta) can deploy your application to a Kubernetes cluster automatically, but this deployment may stop working in case the cluster needs to restart the pods, for example if they are moved and the source image cannot be found in the cache.

With GitLab 10.5, public projects automatically set the cluster so it can access the GitLab Container Registry even after the deployment pipeline ended, creating a more stable environment for your applications.

Read more about Auto DevOps (Beta)

Allow developers to create projects in groups

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.

Allow developers to create projects in groups

Read through the documentation on Groups

Seamless Prometheus integration on Kubernetes

In GitLab 10.4 we added the ability to deploy Prometheus into a connected Kubernetes cluster with a single click. In this release we are making further improvements by automatically enabling the project’s Prometheus integration.

GitLab utilizes the Kubernetes API to query the deployed Prometheus server without requiring it to be accessible outside of the cluster.

Learn more about monitoring applications with Prometheus

Global Search API

We’ve added global search support for the GitLab API. This is taking our existing global search capability used in the GitLab native web UI, and wrapping it in the API to allow external systems to take advantage of the functionality.

This allows teams to create custom workflows, for example, searching for content in files and reporting statistics on those results.

The API works regardless of whether you have Elasticsearch (available only for GitLab Starter or above) configured or not.

Read through the documentation on Global Search API

Labels list page redesign

We’ve cleaned up the labels list page design so you can more easily parse through labels and manage them individually. The icons have also been refreshed per our new icon designs. Also, we’ve rearranged the links to issues and merge requests (of a given label), to take up less horizontal space, making the overall experience better.

Labels list page redesign

Read through the documentation on Issues

Links to merge requests related to a commit now appear on the commit page itself. This is very useful when you are reviewing the commit history of a repository, and want to know the greater business and technical context of a commit. You can now easily navigate to the merge request that introduced the commit, from the commit page itself. From the merge request, you can see all the previous technical conversations, and if the issue has been linked (via the issue closing mechanism for example), then you can even navigate back to the issue to see the business context.

Thank you @hiroponz for the contribution!

Navigate to related merge requests from commit page

Read through the documentation on Related Merge Requests in Commit

Improved internationalization

As part of our ongoing effort to internationalize GitLab, we have now externalised strings in the Issues and Merge Request sidebars, Repository Charts page, and Repository Graph page, allowing our translation community to add more languages and strings to GitLab.

If you are interested in contributing to GitLab’s Internationalization efforts, we welcome you to join our translation community.

Read through the documentation on translating GitLab

Hashed storage is now Beta

Hashed Storage is a new storage behavior introduced in 10.0. Instead of coupling project URL and the folder structure where the repository will be stored on disk, we are coupling a hash, based on the project’s ID. This makes the folder structure immutable, and therefore eliminates any requirement to synchronize state from URLs to disk structure. This means that renaming a group, user, or project will cost only the database transaction, and will take effect immediately.

Read through the documentation on Hashed Storage.

Omnibus improvements

  • GitLab Mattermost 4.6 includes faster channel load times and enhanced 508 compliance.
  • Chef has been upgraded to 12.21.31
  • Chef Omnibus has been updated to 5.6.3.
  • SELinux rules have been added to allow fast SSH key lookups.

Read through the documentation on Omnibus GitLab

GitLab Runner 10.5

We’re also releasing GitLab Runner 10.5 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


Mattermost configuration changes

With the release of GitLab 11.0, the number of Mattermost configuration options supported within gitlab.rb will be reduced. We will continue to support the core configuration settings necessary to run Mattermost, and set up the integration with GitLab. Going forward, other configuration settings should be set directly within the Mattermost console, or passed as environment variables.

Presently with two applications attempting to write to the same config file, changes can be lost.

Due: GitLab 11.0.

The gitlab Helm chart

The gitlab Helm chart is deprecated. For installations on Kubernetes today, we recommend the beta gitlab-omnibus Helm chart.

A new cloud native GitLab chart is in development with increased scalability, resilience, and other benefits. This chart will replace both existing charts when available later this year.

For more information on GitLab Helm charts, please see our documentation.

Due: March 22, 2018.

Upgrade barometer

To upgrade to GitLab 10.5 from the latest 10.4 version, no downtime is required.

For this release we have migrations and post-deploy migrations.

GitLab.com migrations took approximately 35 minutes and post-deploy migrations amounted for a total of around 16 minutes.

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

Bug in git_data_dirs

GitLab 10.5.0 Omnibus packages have a bug in the handling of the git_data_dirs. If your section is formatted like:

  "default": {
    "path": "/path/to/storage"

You will see an error on running gitlab-ctl reconfigure. As a workaround, please use the following syntax instead:

  "default" => {
    "path" => "path_to_storage"

We are resolving this issue in 10.5.1 Omnibus packages.


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


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


Check out our update page.

GitLab Subscription Plans

GitLab is available in self-hosted and cloud SaaS options.

Self-hosted: Deploy on-premises or on your favorite cloud platform.

  • Libre: For small teams, personal projects, or GitLab trials with unlimited time.
  • Starter: For co-located teams with few projects who need professional support.
  • Premium: For distributed teams who need advanced features, high availability, and 24/7 support.
  • Ultimate: For enterprises that want to align strategy and execution with enhanced security and compliance.

Cloud SaaS - GitLab.com: hosted, managed, and administered by GitLab with free and paid subscriptions for individuals and teams.

  • Free: Unlimited private repositories and unlimited collaborators on a project. Private projects get access to Free features, public projects get access to Gold features.
  • Bronze: For teams that need access to more advanced workflow features.
  • Silver: For teams that need more robust DevOps capabilities, compliance and faster support.
  • Gold: Great with many CI/CD jobs. Every public project get the features of Gold for free irrespective of their plan.

Cover image licensed under Unsplash free license

For the latest and most detailed news follow @gitlab on Twitter. Future blog posts suggestions RSS

Install GitLab in 2 minutes

With Ubuntu, Debian, CentOS, openSUSE, and Raspbian packages or from source

Install GitLab Now

Try GitLab Enterprise Edition risk-free for 30 days.

No credit card required. Have questions? Contact us.