GitLab 12.4 released with improved Merge Request Dependencies and Audit API
GitLab 12.4 is now available with several improvements for governance including an Audit API, Code Owner approvals for Protected Branches, and Access Control for Pages. Merge Request Dependencies help you orchestrate work across teams, while so many more exciting features help you be more efficient and deliver better software faster!
GitLab 12.4 is released with several improvements for governance including an Audit API, Code Owner approvals for Protected Branches, and Access Control for Pages. Merge Request Dependencies help you orchestrate work across teams, while so many more exciting features help you be more efficient and deliver better software faster!
Merge Request Dependencies
GitLab can help you improve visibility, collaboration, and productivity. When developers work together to achieve a larger goal, their small changes often need to be merged in a specific sequence to work as intended. To simplify this, Merge Request Dependencies allow dependencies to be defined in merge requests, preventing changes from being merged in the wrong order while also improving the visibility of dependencies during code review. This feature was introduced as Cross-Project Merge Request Dependencies in 12.2 but has been renamed to Merge Request Dependencies, and expanded to support more types of dependencies. This includes both cross-project and Merge Request Dependencies within the same project.
We recognize governance is important to you. Here are a few of the key features in 12.4 that will make governance easier for you.
Audit Events API
GitLab helps you achieve end-to-end visibility across your development lifecycle while streamlining processes. To facilitate this, GitLab plays well with others and, in 12.4, is introducing an API for instance-level audit events. Audit Events are a powerful way to better understand adherance to policies. Using the new Audit Events API, administrators can obtain events programmatically and better enable powerful alerting and monitoring that meets specific needs.
Pages Access Control on GitLab.com
Access control for Pages has been available for self-managed but is now available on GitLab.com. It allows an authorized administrator to restrict access to a Pages site or make it available to the public. This is a community contribution that we are very excited to have enabled on GitLab.com!
Code Owner Approvals for Protected Branches
Another feature to aid in governance is the new Code Owner Approvals for Protected Branches. Using merge request approvals to restrict how code is pushed to protected branches is helpful for promoting code quality and implementing compliance controls. However, not all merge requests target stable branches, and not all stable branches need the same controls. In GitLab 12.4, it is possible to prevent directly pushing changes to files or merging changes without the code owner's approval for specific branches.
Be sure to catch the recap of our first European user conference from October 9th. The next GitLab Commit User Conference will be in San Francisco in January. Registration is now open.
Tuomo’s contribution to GitLab 12.4 enabled private project support for
viewing HTML
artifacts, a
highly requested feature with almost 300 upvotes! This is Tuomo’s second MVP,
their first was in GitLab
11.5
where they implemented Access control for
Pages.
Thank you for your contributions and for engaging with us over the last year
- we truly appreciate it!
Developers often work together to achieve a larger goal through
many small changes. These changes need to be merged in a specific
sequence to work as intended, but keeping track of these dependencies
can be confusing and error prone.
Merge Request Dependencies allow dependencies to be defined in merge
requests, to prevent changes from being merged in the wrong order. This
also increases the visibility of dependencies during code review to help
the reviewer understand the full scope of the proposed changes. This
feature was introduced in
12.2
but in 12.4 it has been improved to also support Merge Request
Dependencies within the same project.
Audit Events
are a powerful way to better understand activity inside GitLab.
Organizations may rely on audit events to ensure that user activity
adheres to policies; for enterprises operating under regulatory
scrutiny, this can be of critical importance.
To make audit events easier to use for automation, we’re
introducing an API for instance-level audit events. Using the Audit
Events API, administrators can obtain events programmatically and better
enable your own powerful alerting and monitoring that meets your
organization’s specific needs.
Using merge request approvals to restrict how code is pushed to
protected branches is helpful for promoting code quality and
implementing compliance controls. However, not all merge requests target
stable branches, and not all stable branches need the same controls.
In GitLab 12.4, it is possible to require Code Owner approval for
specific branches to prevent directly pushing changes to files or
merging changes without a code owner’s approval.
If code owner approval was required using the previous Project
setting, this has been applied to your existing Protected Branches.
Access Control for Pages
allows an authorized administrator to restrict access to a Pages site or
make it available to the public. Now, content published by your private
projects can require sign in to protect the contents of the published site,
making it easier to publish and control access to internal documentation.
You can now subscribe to updates about new releases in a project, so
that you will be notified about new versions, even for projects you are
not part of. This can be used to stay up to date on new releases from
projects that you depend on, without having to check-in manually.
Previously, GitLab logs were primarily accessed via the Environments page.
This made it difficult to easily switch between logs from different environments
for troubleshooting purposes. It also prohibited direct access of logs without
first accessing a specific Environment.
Now, with GitLab 12.4, we’ve enabled the ability to view any logs from
any environment or pod. From the environments page, you’ll see two
buttons to view any pod logs from your Kubernetes clusters. Going forward
we’ll continue to improve how you can access your logs including creating
a Logging link directly in your Operations menu.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Versions of Cert-Manager prior to 0.8.0 will be blocked by Let’s Encrypt starting Nov. 1st
Prior to GitLab 12.4, the Kubernetes integration provided users the option
to install Cert-Manager v0.5.2 onto their Kubernetes cluster. Let’s
Encrypt will block requests from versions of Cert-Manager less than
0.8.0
starting on November 1st, 2019. To resolve this, users must uninstall
Cert-Manager then install Cert-Manager again. You should consider backing
up
any additional configuration prior to upgrading in the event of data loss.
Move protected paths configuration from gitlab.rb to the GitLab UI
The configuration of protected paths has been moved to the GitLab UI so
that there is a single place to configure all settings related to
throttling. Previously, user and IP limits were set in the UI, and
protected paths were set in /etc/gitlab/gitlab.rb. Configuring protected
paths in gitlab.rb has been deprecated in GitLab 12.4 and is scheduled
for removal in GitLab 13.0. For details on how to configure protected
paths in the UI, and migrating protected path throttles from Omnibus
GitLab 12.3 (or earlier) to the UI, see the protected paths
documentation.
As we continue to improve and enhance our integration with Elasticsearch,
support for Elasticsearch 5.6.x will end with the release of GitLab 12.7.
Elasticsearch 5.6 has also reached its end of
life with the release of
Elasticsearch 7.x.
Updated version
requirements
for GitLab 12.7 will include support for only Elasticsearch 6.x. At this
time there is no timeline for support of Elasticsearch 7.x with GitLab;
you can follow this
issue for updates.
GitLab recommends self-managed customers upgrade to ElasticSearch 6.x.
openSUSE 15.0 reaches end of life at the end of November 2019. Support for
openSUSE 15.0 will be dropped in GitLab 12.5. Issue
4404 tracks the
work to build packages for openSUSE Leap 15.1.
GitLab 12.4 now installs Knative 0.7 as a GitLab Managed
App.
Note: GitLab Serverless is still in alpha. If you run into issues with
previous Knative versions, please reach out to the GitLab support.
Starting with GitLab 12.4, the Kubernetes integration will install
Cert-Manager v0.9.1. If you installed Cert-Manager via the Kubernetes
integration previously, then you will be on an older version. Older
versions will be blocked by Let’s
Encrypt
starting November 1st, 2019. See more info on the
Cert-Manager deprecation notice.
GitLab 12.3 upgrades Cert-Manager to v0.9.1 when installing it through the
Kubernetes integration. If you are using an older version of Cert-Manager
(installed through the Kubernetes integration) you will need to uninstall
the old version and install the latest version as older versions will be
blocked by Let’s
Encrypt
starting November 1st, 2019. See more info on the
Cert-Manager deprecation notice.
To help with the larger migrations we have introduced background
migrations for
this release. Background migrations are Sidekiq jobs that will run
asynchronously. For GitLab.com these migrations took around 36 hours to
complete, and no side effects were expected nor present. To find the
approximate time (in hours) it will take to complete these migrations on your instance
run the following command from a Rails console: (Project.count.to_f /
300_000).ceil. You can check the status of background migrations by running
this command from a Rails console:
Sidekiq::Queue.new('background_migration').size.
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