10.5

GitLab 10.5 Release

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

MVP This month's Most Valuable Person (MVP) is awarded to 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!

10.5 Key improvements released in GitLab 10.5

Instant SSL with Let’s Encrypt for GitLab

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

Include external files in CI/CD pipeline definition

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.

Include external files in CI/CD pipeline definition

Gemnasium dependency checks

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.

Gemnasium dependency checks

Track additional browser performance metrics

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.

Track additional browser performance metrics

Git LFS 2 locking support

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.

Git LFS 2 locking support

10.5 Other improvements in GitLab 10.5

View Epics in roadmap

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

Dynamic management of secret variables

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

Instance level domain for Auto DevOps

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.

Transfer groups

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

Deployed Ingresses now configured for Prometheus metrics

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.

Approve additionally in Merge Requests

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

View all issues of all subgroups on group issues page

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

Color chips in GitLab Flavored Markdown

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

Push to create a project

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!

Single secondary Disaster Recovery is now Generally Available

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.

Epics search and filter bar

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

Persistent public projects deployments

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.

Allow developers to create projects in groups

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

Seamless Prometheus integration on Kubernetes

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.

Global Search API

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.

Labels list page redesign

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

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

Improved internationalization

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.

Hashed storage is now Beta

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.

Omnibus improvements

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.

GitLab Runner 10.5

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.

Deprecations Deprecations

Mattermost configuration changes

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.

Planned removal date: GitLab 11.0.

The gitlab Helm chart

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.

Planned removal date: March 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 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:

git_data_dirs({
  "default": {
    "path": "/path/to/storage"
  }
})

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

git_data_dirs({
  "default" => {
    "path" => "path_to_storage"
  }
})

We are resolving this issue in 10.5.1 Omnibus packages.

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 free license

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