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.
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.
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.
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.
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
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!
Key improvements released in GitLab 10.5
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.
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.
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.
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.
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.
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.
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.
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
Making it easier to structure groups and subgroups, you can now take an entire
GitLab group and transfer it into another group.
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
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.
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.
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!
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
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.
Performance improvements
Some of the more noteworthy performance improvements in GitLab 10.5
include:
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.
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
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.
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
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
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.
Navigate to related merge requests from commit page
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!
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 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
- 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
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
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
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
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
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
Please check out the changelog to see all the named changes:
Installing
If you are setting up a new GitLab installation please see the
download GitLab page.
Updating
Check out our
update page.
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
-
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
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