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.
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.
"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.
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!
Key improvements released in GitLab 10.4
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.
Other improvements in GitLab 10.4
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.
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
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
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
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.
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.
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.
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
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
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.
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.
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.
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
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
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
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
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
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.
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
The complete list of all removed features can be viewed in the GitLab documentation.
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
