10.4

GitLab 10.4 Release

GitLab 10.4 released with Dynamic Application Security Testing and Web IDE (beta)

GitLab 10.4 released with Dynamic Application Security Testing, SAST for Docker Containers, Web IDE editor (beta), and improvements to Epics, Merge Requests, Geo, Runner, Git LFS, SSH, Monitoring, and Auto DevOps!

In this month's release of GitLab 10.4 – the first of 2018 – we've added capabilities to improve planning, testing, merge requests, and deployment. This release also includes new security testing capabilities and the first iteration of our Web IDE, part of our ambitious product vision for Complete DevOps.

Security testing

As part of Complete Devops, we want to offer powerful security tools out of the box. We recently released static application security testing and are now expanding that with Dynamic Application Security Testing (DAST) and Static Application Security Testing (SAST) for Docker Containers. DAST, SAST for Docker Containers, and Browser Performance Testing have also been added as a best practice to Auto DevOps.

Faster editing

"If you can do it in less than two minutes, do it now" states the two-minute rule of Getting Things Done. Writing a small fix or correcting a typo should be fast, but this is rarely the case when we need to stash changes and switch to a different context.

Delaying a fix or waiting to address feedback on a merge request increases cycle time, and it's even worse for distributed teams where hours quickly become days, all for avoiding a git stash. The new editor, which is the first release of the GitLab Web IDE, makes it easier to contribute changes like these from the GitLab interface.

See all the features

We've also shipped many exciting improvements this month to Epics, Merge Requests, Geo, Runner, Git LFS, SSH, Monitoring, and Auto DevOps.

Read on to learn more about all of the key features shipped in 10.4!

GitLab MVP badge

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

George, a first-time contributor in GitLab 10.4, has worked consistently over the last month polishing the GitLab interface with seven contributions, including fixes to sidebar icon alignment and typographic hierarchy in user settings.

Thank you, George, for your contributions and eye for detail! We’ve sent George some GitLab swag as a thank you, including a hoodie, socks, and a handmade tanuki.

10.4 Key improvements released in GitLab 10.4

Dynamic Application Security Testing (DAST)

Dynamic Application Security Testing (DAST)

Running static checks on your code is the first step to detect vulnerabilities that can put the security of your code at risk. Yet, once deployed, your application is exposed to a new category of possible attacks, such as cross-site scripting or broken authentication flaws.

Spotting problems automatically gets even better in GitLab 10.4, adding Dynamic Application Security Testing (DAST) to audit a live version of your application, for example the Review App created in a previous job, directly from your CI/CD pipeline. Results are shown in the Merge Request to give easy access to them. Starting with GitLab 10.4.2, Auto DevOps will run DAST automatically against the Review Apps of your application.

Dynamic Application Security Testing (DAST)

SAST for Docker Containers

SAST for Docker Containers

Modern applications that run inside of Containers are more secure because the code is separated from other Containers on the same host. But even if your code is safe, the environment it runs on may contain flaws that can impact the security of the entire application, for example, a vulnerable system library.

GitLab 10.4 includes the ability to run security checks on the image that contains your application and to report possible warnings in the Merge Request before merging the changes into the stable branch. These checks are part of Auto DevOps to provide security by default.

SAST for Docker Containers

Web IDE Editor (Beta)

Web IDE Editor (Beta)

With the introduction of the new editor (beta) as the first feature of the Web IDE, we are making it faster and easier to contribute small fixes and resolve merge request feedback by eliminating the need to stash changes and switch branches locally.

In upcoming releases we will integrate the Web IDE more deeply with merge requests and improve commit staging, and ultimately add live previews and a web terminal so anyone can contribute.

While in the early stages of the Beta, access to the Web IDE is by opting in. To enable the Web IDE, click on your profile image in the top right corner and navigate to Settings > Preferences, enable the Web IDE and Save.

Web IDE Editor (Beta)

Rebase and fast-forward in CE

Rebase and fast-forward in CE

You can now rebase and fast-forward merge directly in the merge request web UI in GitLab CE. You don’t need to jump between GitLab and your local command line anymore while doing these activities; you can do it in a single flow right inside GitLab.

This feature was previously EE only. In support of GNOME’s move to GitLab CE we are excited to bring rebase and fast-forward merge to GitLab CE.

Rebase and fast-forward in CE

10.4 Other improvements in GitLab 10.4

Reordering Issues in Epics

Reordering Issues in Epics

Epics allow you to manage a list of associated issues that together share a theme. Often an epic represents a large feature that has been separated into multiple issues to be worked on across multiple milestones.

Depending on an organization’s workflow, they may want the list order in epics to reflect different scenarios. This could be priority, difficulty, feasibility, or order of implementation.

Some organizations might want to put closed issues near the top, while others might want them near the bottom. With this release, users can now reorder the issues in an epic by simply dragging and dropping, similar to that in Issue Boards.

Reordering Issues in Epics

Group Issue Boards API

Group Issue Boards API

Similar to Project Issue Boards, you can now manage Group Issue Boards through the API, starting in this release, providing further flexibility and opportunities for automation in managing your individual team workflows.

For example, some teams have certain custom business requirements to move issues automatically between board columns under certain conditions. This is now possible for group issue boards through the API.

Fast SSH key lookup in CE

Fast SSH key lookup in CE

When authorizing a user, OpenSSH uses linear search to find a key. This means that SSH operations become slower as the number of users on a GitLab instance grows. For large instances significant time and disk I/O may be required to fulfill a request, making Git over SSH slow.

In GitLab 9.3 fast SSH key lookup was added to GitLab EE. This authorizes SSH users via a fast, indexed lookup in the GitLab database instead of the default slow linear search. GitLab CE is designed for small teams, and as a result did not previously include this optimization. However, in support of GitLab’s Cloud Native Helm Charts, all parts of the code base will need to support fast SSH key lookup and has thus been added to GitLab CE.

GitLab Geo support for HA now Generally Available

GitLab Geo support for HA now Generally Available

In GitLab 10.2 both Geo and Postgres HA individually reached general availability (GA), but the use of Geo in combination with HA was considered Beta.

Configurations using GitLab Geo in combination with HA are now considered GA. This allows geographically distributed teams to enjoy faster Git fetch operations using GitLab Geo and the increased redundancy of highly available configurations

Improved environment performance dashboard

Improved environment performance dashboard

In GitLab 10.4 we have improved the design of the environment performance dashboard, which displays the system and response metrics captured by Prometheus.

Now, when reviewing metrics at a specific point in time, they are clearly displayed on the hover over instead of in the chart’s legend. In an upcoming release, we will add summary metrics to the legend, displaying statistics such as the maximum throughput, or average latency over the time span.

Improved environment performance dashboard

Clear the Runner cache

Clear the Runner cache

GitLab Runner uses a cache to speed up execution by reusing existing data between different jobs. But sometimes it leads to inconsistent behaviors, for example, when the local copy of the repository is modified by one job, and the new changes impact the execution of the following one.

In GitLab 10.4, we introduce a new button in the Pipelines page that can be used to clear any existing cache for the specific project and start fresh with a new one. This immediately solves the problem of “dirty” runs.

Clear the Runner cache

Run a scheduled pipeline manually

Run a scheduled pipeline manually

Scheduled pipelines are very useful to run recurring jobs without a manual action by the user. They are normally used to perform maintenance tasks, or to create nightly builds for your software. But sometimes that exact scope is also needed on-demand, and recreating the same environment (e.g., adding custom variables) can be hard and time consuming.

GitLab 10.4 introduces the ability to run a scheduled pipeline manually, directly from the web interface: a “play” button can be found for each schedule in the list, and running the pipeline is just as simple as a click.

Run a scheduled pipeline manually

Omnibus improvements

Omnibus improvements

  • GitLab Mattermost version 4.5 includes Zoom plugin for video, audio, screen sharing, and much more.
  • CA certificates have been updated to 2017.09.20
  • GitLab Monitor has been updated to 2.4.0
  • Ruby has been updated to 2.3.6
  • Go based libraries such as Registry, Workhorse, and Prometheus are built with Go 1.9.2

Epics API

Epics API

With this release, the GitLab API supports Epics. So you can now manage individual epics, lists of epics, and all epic attributes (title, description, and dates) through the API, allowing your team to create custom and/or automated workflows outside of GitLab.

Managing the list of issues associated with an epic is also supported, including the newly introduced reordering capability.

Easily deploy Prometheus on Kubernetes

Easily deploy Prometheus on Kubernetes

GitLab can now deploy Prometheus into a connected Kubernetes cluster with a single click, making it easier than ever to begin monitoring the performance of your application. System metrics like processor and memory utilization latency are automatically retrieved from Kubernetes, and response metrics like latency and throughput are available with a supported ingress. To get started, connect a cluster at CI/CD > Clusters.

If GitLab has network connectivity to Prometheus, Prometheus integration can be enabled to analyze and display these metrics directly within GitLab. In the next release, GitLab 10.5, integration will be automatically enabled and will not require direct network access, offering seamless integration.

Easily deploy Prometheus on Kubernetes

Status icon for LFS-tracked files

Status icon for LFS-tracked files

Identify which files are tracked by Git LFS with the new LFS tracking status icon shown in blob views and file lists, including the merge request change list. This makes it possible to verify binary files are correctly tracked by LFS when reviewing a merge request.

Status icon for LFS-tracked files

Browser Performance Testing now included in Auto DevOps

Browser Performance Testing now included in Auto DevOps

In 10.3 we added Browser Performance Testing to easily determine the performance impact of a change for web apps, prior to merge. To use this feature, it was necessary to add an additional job to your .gitlab-ci.yml and adapt to your needs.

In GitLab 10.4, Browser Performance Testing is now included in Auto DevOps as well, providing automatic performance analytics of the root page with zero configuration.

If you’d like to test add additional pages, simply add the relative paths to a .gitlab-urls.txt file in the root directory of the repository.

Browser Performance Testing now included in Auto DevOps

Support for openSUSE Leap 42.3

Support for openSUSE Leap 42.3

With GitLab 10.4, Omnibus packages are now available for openSUSE 42.3.

This will be the last release with support for openSUSE 42.2, as it is being officially discontinued.

GitLab Clusters now Generally Available

GitLab Clusters now Generally Available

With GitLab 10.4, we are proud to announce that the Kubernetes cluster integration is now Generally Available! You can connect your existing clusters to your project, or create new ones on Google Kubernetes Engine (GKE) with a few clicks of your mouse, using the new Clusters page, under the CI/CD section.

The old Kubernetes integration service is still accessible, but it can be used only if it was enabled before the upgrade to GitLab 10.4. In the upcoming releases, the existing data will be migrated to the new Cluster page and the integration page will be eventually removed. Service Templates, available in the Admin area, are working as usual.

GitLab Runner 10.4

GitLab Runner 10.4

We’re also releasing GitLab Runner 10.4 today! GitLab Runner is the open source project that is used to run your CI/CD jobs and send the results back to GitLab.

The most interesting changes:

List of all changes can be found in GitLab Runner’s CHANGELOG.

Performance improvements

Performance improvements

We are continuing to make great strides in improving the performance of GitLab in every release. We’re committed not only to making individual instances of GitLab even faster but also greatly improving the performance of GitLab.com, an instance that has over one million users!

In GitLab 10.4 we are shipping performance improvements for issues, merge requests, repositories and API. Some of the more noteworthy improvements include:

Deprecations Deprecations

End of support for the openSUSE 42.2 Omnibus package

End of support for the openSUSE 42.2 Omnibus package

GitLab 10.4 will be the last version to include support for openSUSE 42.2, as it will be officially discontinued by January 16, 2018. GitLab packages are now available for openSUSE 42.3.

Planned removal date: January 22, 2018.

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.

API V3

API V3

In GitLab 8.17 we announced the deprecation of API v3.

We are still seeing a high volume of traffic on GitLab.com using API v3 requests.

API v3 will be removed in GitLab 11 and we just wanted to ensure that developers were migrating to API v4. Please refer to our documentation that shows changes between the two API versions.

Planned removal date: GitLab 11.0

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.4 from the latest 10.3 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 background migrations.

You can check the status of background migrations by running this command from a Rails console: Sidekiq::Queue.new('background_migration').size

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