Use Jaeger in the GitLab UI
Tracing provides insight into the performance and health of a deployed
application by tracking each function or microservice which handles a
given request.
Jaeger is an open source, end-to-end distributed tracing system used for
monitoring and troubleshooting microservices-based distributed systems.
With GitLab 12.4, users that are using Jaeger can access it and view the
performance and health of their deployed application without
leaving the GitLab UI.
Variable Expansion Support for Multi-project Pipelines
When using a multi-project pipeline flow, where one pipeline triggers
another, it’s often helpful to be able to store a dynamic value in a
variable upstream that you can reference in the downstream pipeline. For
example, if a pipeline is running on a branch and you want
the $CI_COMMIT_REF_NAME on that branch accessible throughout all of the
downstream pipelines.
Previously, the variable didn’t expand so calling a variable downstream
via the trigger keyword failed with a no ref name error. Getting
this workflow to work required spawning a separate job whose only
purpose was to execute a cURL command to kick off the next pipeline
passing in the variable state. In addition to requiring extra set up and
extra resources to run this workaround loses the ability to visualize
the relationship between pipelines in the UI.
Now GitLab will expand variables used inside of the branch
property of the trigger keyword, simplifying your pipeline design and
adding more flexibility around how your pipelines trigger each other in
multi-project scenarios.
DAST for the Master Branch
We are pleased to announce that DAST scans can now run against a project’s
default branch inside a dedicated review app. Previously, DAST only ran
against feature branches. This enhancement allows the creation of a DAST
results baseline on the default branch against which MRs are compared.
With this, you can pinpoint the exact branch where new security issues
are introduced.
Check for Existence of Files in Pipelines
Adding to the rules: syntax initially introduced in GitLab 12.3,
the new rules:exists rule is able to accept an array of paths and will
match if any of these paths exist as files in the repository.
This is useful in cases where you want to run a CI job only if a certain
file exists. For example, only run the tests pipeline when the file
tests.yml exists. Use of this rule can help speed up pipelines by
skipping stages with no match.
Native Geo Support for Object Storage Replication
In GitLab 12.4, Geo natively supports replicating data in object
storage such as LFS objects, job artifacts, and uploads. Previously, Geo
could be configured to work with object storage; however, the
replication of the content was always left to the object storage
provider. This imposed limitations when users relied on local storage
appliances that do not support any replication logic.
Native Geo support allows data to be replicated across different object storage
providers in different regions (e.g. Amazon in Europe and Microsoft in
the United States). Geo users can also use local storage, for example
via MinIO, and use Geo to replicate data to secondary nodes.
Native Geo support for object storage replication is currently a beta
feature and is not
ready yet for production use.
Improved large file handling via Git Partial Clone (alpha)
Storing large binary files in Git has typically been discouraged to
prevent the repository growing too large, making cloning and fetching
changes very slow. Solutions like Git LFS have provided a workaround
by storing large files outside the Git repository, and downloading
large files on demand.
In GitLab 12.4, we are adding experimental support for Partial Clone,
which allows large files to be excluded when cloning a repository and
fetching updates. This removes the need to choose which files should
be stored in Git and which files should be stored outside the
repository using Git LFS. Partial Clone support is disabled by
default, but can be enabled per project, and requires at least Git
2.22.0.
In comparison with Git LFS, instead of requiring large files to be
specially handled when authoring the commit, Partial Clone allows
developers, CI runners, or any other Git client to specify which files
they want to download. This removes the need to teach people which
files should go in Git LFS, avoids the problems of trying to rewrite
history to migrate large files to Git LFS, and bypasses the
frustrations caused by someone accidentally pushing an large file to
the Git repository when it should have gone to Git LFS. Simply, large
files should just work.
Date Picker for Productivity Analytics
Until now, users were not able to select a specific date range for their
metrics in cycle analytics and productivity analytics. This meant that
they cannot drill down or report into productivity during a specific
sprint or a custom date range since we only provided preset periods such
as 7, 30, 60, 90 days. With the release of this feature, users will be
able to visualize how their data looks over any time frame and
the periods that actually matter to them.
Use VPC Native Setting by Default When Creating GKE Cluster in GitLab
Google Kubernetes Engine provides the ability to create
VPC-native
clusters, which rely on Alias IPs and provide integrated VPC support for
container networking, resulting in a more scalable, secure, and simple
system that is suited for demanding enterprise deployments and use
cases.
Starting with GitLab 12.4, GitLab’s GKE integration will enable this
option by default when creating a GKE cluster.
Restrict Permissions for Manual CI Jobs
Teams often need to create manual jobs to handle things like
deployments, soft approvals, or other gates, but in GitLab it’s not
obvious how to restrict these permissions to prevent just anyone from
completing the action.
This was actually already possible in GitLab today, but wasn’t clearly
documented. In this release we’ve significantly improved the
documentation for protecting manual
jobs
to make it more clear how to get this set up.
Delete Designs in Design Management
Sometimes mistakes happen or design goals change and the ability to
remove a design from a revision can be important. With deletions in
Design Management users can select one or more designs and remove them
from the latest version. This enables the latest version of the design
to represent the true state of ideas.
Enrich Environment and Deployment API
We have added API functionality that will return the state and last
deployment attributes of environments. An example use of that
information is to write a script to delete unused environments.
Improved Geo Upgrade Documentation
As part of our effort to simplify the Geo upgrade
process, we reworked
large parts of the Geo upgrade documentation. GitLab Geo can be deployed
in different configurations and depending on the configuration Geo
upgrades require different steps. At this moment, upgrading Geo is still
highly manual and can involve many individual steps. To improve this in
an iterative way, we focused first on improving the Geo upgrade
documentation
itself. This ensures that the documentation is up-to-date and covers all
use cases.
We rewrote the general update
steps, archived old
update steps,
updated zero-downtime upgrade instructions for simple
deployments and
investigated many other parts of the
documentation.
We are also working on instructions for zero-downtime updates of a
multi-node, high-availability Geo
cluster; however,
these instructions require more testing before we release them.
Following this work, we will work on better automation, improved
testing, and making certain upgrade procedures more robust.
MR links are now shown on Pipeline view
When viewing a pipeline, it can be helpful to be able to navigate to the
merge request(s) associated with that pipeline. We’ve added links
directly to the related merge requests to make this simpler and more
efficient.
Insert jobs at beginning or end of pipeline via include
A common use case for includes is to add a job at the beginning or end
of a pipeline. However, as the author of a shared include, you don’t
necessarily know what the first or last stages will be called. This
makes it difficult and error prone to try to write a job that runs at
the start or end of a pipeline.
In GitLab 12.4, .pre and .post pipeline stages that
are guaranteed to run at the beginning or end of a pipeline to make this
easier are available.
Upgraded Kubernetes NGINX Ingress Application when Installed via Kubernetes Integration
Keeping your Kubernetes-deployed apps running on the latest version
ensures you have the newest features as well as up-to-date security.
GitLab 12.4 allows you to use the latest NGINX Ingress application when
installing it
using GitLab Managed Apps. To upgrade an existing version,
uninstall
and reinstall the Ingress application using GitLab.
API Endpoint for ‘Static Status Check Names’ in GitHub Integration
It is now possible to configure the static status check names in the
GitHub integration via the API, making it much easier to change this
setting on large numbers of projects.
GitLab Runner 12.4
We’re also releasing GitLab Runner 12.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.
Changes include:
The list of all changes can be found in GitLab Runner’s CHANGELOG.
Performance improvements
We continue to improve the performance of GitLab with every release
for GitLab instances of every size.
Some of the improvements in GitLab 12.4 are:
Admin Override of Artifacts Size per Project/Group
Currently, the artifacts size is set to 100MB by default but some
projects need the ability to go over these limits, subject to the
discretion of the administrator. To enable this, we’ve added an option
in group and project settings to override the global artifacts size
limit, similar to how the repository size limit can be customized.
Private Project Support for Online View of HTML Artifacts
Viewing HTML artifacts in a browser window is a key efficiency
workflow. Because of how frequently this task is performed, being able
to quickly go from browsing your artifacts to opening and reviewing them
is important. Without an online view, you need to download the artifact
and spin up a webserver locally to view the report. Doing this for every
HTML artifact for all of your builds can become an intrusive time-sink
that interrupts the flow of work with continual context-switching.
Previously, it was possible to view HTML artifacts in a browser window
using GitLab Pages instead of downloading them locally, but this
capability was limited to public projects only. This was a problem for
many businesses and organizations that use GitLab predominantly with
private projects - an online view was simply not available to them. Now
thanks to a wonderful community contribution from Tuomo
Ala-Vannesluoma, we have added support for
online view of HTML artifacts to private projects
as well. Note that this requires enabling access control for GitLab
Pages
to work correctly.
Enable “Cloud Run on GKE” When Creating a Cluster via GKE Integration
When creating a Kubernetes cluster via GitLab’s GKE integration, users
can now optionally enable “Cloud Run on GKE” with a single click. GKE
will automatically provision the cluster with Knative serving, Istio,
and HTTP load balancing. When installed, users can continue to take
advantage of the features offered by GitLab
Serverless
to deploy Knative services with minimal configuration.
Note: Cloud Run for GKE has recently been rebranded as “Cloud Run for
Anthos”. We plan to update the name of this feature with Google’s
updated branding in next month’s release.
Generic Alert Endpoint MVC
People make use of a variety of different tools to monitor their
application environments. These tools send critical,
time-sensitive alerts when an incident arises and action needs to be
taken. Now, GitLab’s Incident Management capabilities include a generic
REST endpoint where you can send alerts, regardless of the tool that
generated them. When GitLab receives a POST to the endpoint, it will
automatically create an incident issue. The payload is included in the
issue description and commonly used fields are automatically parsed.
This allows you to use GitLab issues as a central place for incident
response leveraging inputs from your other tools.
Please check out a short video that highlights the Generic Alert
Endpoint MVC.
Geo Supports Using a Single, Location-aware Git URL
Geo now supports providing users with a single remote URL that
automatically uses the Geo node closest to them. This means users don’t
need to update their Git configuration to take advantage of closer Geo
nodes as they move. In fact, end users won’t even have to know that they
are using a local Geo node when initially cloning a project. For systems
administrators, it removes the need to maintain different Git
configurations for users in different locations. This is possible
because, Git push requests can be automatically redirected (HTTP) or
proxied (SSH) from secondary nodes to the primary node.
Geo can be configured to use different services, such as AWS
Route53 or
Cloudflare.
Git Activity added to Group IP Address Restriction
GitLab 12.0 saw the introduction of restricting a group’s activity by
IP address. In GitLab
12.3, we included API activity in the access restriction. In GitLab
12.4 we’re extending this further to include Git actions via SSH.
The resulting feature now provides extensive coverage, rejecting UI,
API, and Git activity if they do not adhere to the group’s IP address
restriction. For compliance-minded organizations, especially those on
GitLab.com, this provides an comprehensive and important security layer.
Scatterplot for Productivity Analytics
Previously, users were not able to easily visualize and measure
velocity over time. In order to enable them to do that, we are adding
scatterplots to Productivity Analytics, where users can select ‘Time to
Merge’ or any other merge request related metric in order to spot
relevant trends or outliers. Users can also zoom in on a particular date
range in order to research and analyze specific data sets.
API for Manually Creating Deployments
We have added API functionality that will allow for creating
deployments. This also changes deployments so that the associated CI
build is optional. This is needed to lay the foundation to support
external environments and deployments to GitLab.
One-click Install for Group Runner on Kubernetes
It’s now easier than ever to create a shared Runner at the group level
if you’re using GitLab with Kubernetes. The ability to one-click install
a Runner at the project level has been available for a while, but group
Runners still needed to be installed manually. Now, you can simply click
a button and GitLab will install a shared group Runner for you.
Design Management System Notes
In GitLab 12.2 we released the first iteration of Design Management,
which allowed uploading designs directly to issues. They were uploaded
in a separate tab within issues and their activity wasn’t logged, making
it harder to identify whether there were designs added the issues. From
GitLab 12.4 on, when designs are uploaded, new system notes are output
to the issue’s thread to inform the participants. In a future release,
we’ll bring status and discussion
count indications to
the designs to further inform users on design’s activity.
GitHub Integration Default to Static Status Check Names
We have changed the default setting for our GitHub integration to use
static status check
names
by default on new projects. With static status check names enabled on
the integration page, your GitLab instance host name is going to be
appended to a status check name, whereas in case of dynamic status check
names, a branch name is going to be appended. This is a more sensible
initial setting that will ensure that requiring status
checks
works out of the box for users using GitLab CI/CD with a GitHub
repository.
Multi-Select & Move Issue Cards
Sometimes, it’s the little things that matter. Whether you’re kicking
off your next sprint or you just like to pass the time dragging and
dropping on Issue Boards, you’ll be happy to know that you can now
multi-select issue cards via Cmd + click on a Mac or Ctrl +
click on Windows to move them all at once to a different list.
Sort Packages in the Registry UI
The GitLab Package Registry allows users to build, publish and share
npm,
Maven and
(coming soon)
Conan
packages. GitLab provides a user interface that displays package
metadata and helps users to find their project or group’s packages.
However, until recently, users had to manually scroll through their list
of packages to find the package they were looking for.
In GitLab 12.4, we are happy to introduce sorting to the Package
Registry user interface to improve navigation and discoverability! Now
you can sort packages at the project and group level by created date,
name, version, and type. In the coming milestones, we are working
on adding last commit and
branch and will be
redesigning the user interface to include all relevant
metadata.
Global View for Instance-level Cluster Deployments/Environments
The Environments view was introduced in GitLab
12.3
for group-level clusters. The Environments section of the cluster
page provides an overview of all the projects that are making use of the
Kubernetes cluster, including the deployments/environments that have
been provisioned and the number of pods used by each environment. Now
in 12.4 the “Environments” view is available for instance-level
clusters. Navigate to your instance Kubernetes page and click on the
Environments tab. For group-level clusters, the cluster
“Environments” view has been extended to instance-level clusters.
The “Environments” section of the cluster page provides an overview of
all the projects that are making use of the Kubernetes cluster,
including the deployments/environments that have been provisioned and
the numbers of pods used by each environment.
S/MIME is now configurable in the GitLab Helm chart
Sending emails with an S/MIME signature improves security by reducing
the surface area for phishing, man-in-the-middle, and other attacks.
While the ability to sign notification emails with S/MIME was added to
Omnibus in
12.3, it
wasn’t possible to configure S/MIME when installing GitLab on
Kubernetes. Now, in 12.4, S/MIME parameters for GitLab email
notifications can be configured as a global setting for the GitLab helm
chart.
Upgraded Kubernetes Cert-Manager Application When Installed via Kubernetes Integration
Keeping security certificates for your Kubernetes-deployed apps updated
ensures your applications are securely served without interruption.
Starting with GitLab 12.4 you can now upgrade your Cert-Manager
application using the GitLab Kubernetes integration. To upgrade to the
latest GitLab-supported version, navigate to the cluster page from
Operations > Kubernetes, then uninstall and reinstall Cert-Manager.
Omnibus improvements
- GitLab 12.4 includes Mattermost 5.15, an open source
Slack-alternative. This version of Mattermost
is focused on quality
improvements.
- OpenSSL has been updated to version 1.1.1d, which fixes a number of
CVEs. For information about the changes introduced in this minor
release, visit the OpenSSL
website.
- An option has been added to skip database backups during an upgrade.
Database backups can extend the time required to complete an upgrade,
and in some cases, you may want to skip this step so that the upgrade
finishes quicker. For details on how to skip automatic database
backups during upgrades, see the Omnibus upgrade
documentation.
If you skip the automatic backups, make sure you create your own
before upgrading.
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