Share group access with another group
Groups can be used for organizing projects and groups of people. A
typical usage pattern is to create groups for different teams, e.g.
Engineering, Legal, and Operations, and share relevant projects with each
group.
For large instances with thousands of projects, sharing individual
projects with a group quickly becomes unscalable. To make this easier,
we’re introducing the ability to share a group with another group,
removing the need to share individual project links with a group.
Filter Issues, Merge Requests, Epics, and Issue Boards using an ‘is not’ operator (!=)
Finding precisely the issues, merge requests, and epics you want can be
difficult, especially when you want to omit a subset of the results.
GitLab now supports excluding results while filtering issues, merge
requests, epics, and issues cards within an Issue Board using a not
or an “is not”
(!=) operator.
Browse previous file revisions from the Blame view
The Blame view allows you to trace the history of a file line by line,
and inspect each commit. In GitLab 12.7, you can easily follow the
history of a particular line, using the new button titled View blame
prior to this change.
Thanks Hiroyuki Sato for your
contribution!
Allow pip version to be configured in Dependency Scanning
With GitLab 12.7, you can now install a custom version of pip in
Dependency Scanning by using the
DS_PIP_VERSION variable.
When this is set, it will be passed down to the Dependency Scanning analyzers.
Audit Events for Releases
As a step further into GitLab
Releases, we make
your journey through an audit easier by automatically including events
for creating or editing Releases, downloading artifacts, and
associating or dissociating a milestone from within GitLab’s audit logs.
Use CI/CD to update a Conan repository
We recently launched the GitLab Conan Repository to support C/C++
developers in publishing and downloading their dependencies. However,
in order to leverage GitLab CI/CD, they were forced to use their
user name and password, which is inefficient and a potential security
risk.
In GitLab 12.7, we are excited to announce that users can now leverage
the predefined environment variable, CI_JOB_TOKEN, to authenticate to
their Conan Repository and easily publish and install their dependencies.
Disable user profile name changes
Administrators can now prevent users from changing their profile name to
increase traceability of user actions. This additional control over
identities will allow compliance-minded organizations the ability to
ensure GitLab supports their internal policies for audit logging and
identity verification.
This is an instance-level feature that requires administrative access and is currently available for self-managed customers only. You can follow and contribute to this issue discussing whether to enable this feature for GitLab.com users in a future release.
API for merge requests associated with a deployment
We have added support for an API that retrieves the list of merge
requests shipped within a given deployment. This is useful for tracking
when a merge request was merged to a certain environment.
Guide for Incremental Rollouts with GitLab CI/CD
When rolling out changes to your application, it is possible to release
production changes to only a portion of your Kubernetes pods as a risk
mitigation strategy. By releasing production changes gradually, error
rates or performance degradation can be monitored, and if there are no
problems, all pods can be updated. GitLab supports both manually
triggered and timed rollouts to a Kubernetes production system using
Incremental Rollouts, to support both Continuously Delivered and
Continuously Deployed applications. They are already available in Auto
DevOps projects. We have prepared a new guide that shows how to achieve
the same result when using only GitLab CI/CD.
Toggle Feature Flags directly from the list
Feature Flags allow you to enable or disable a recently introduced
feature in your production environment, to reduce the risk of breaking
your application until the feature is fully tested. Now you can
conveniently toggle flags on or off inside GitLab directly from the
Feature Flag list. Previously, feature flags could only be toggled using
the API.
Ignore Sentry errors from GitLab
Errors can be noisy and plentiful which makes triage processes
time-consuming, because it is difficult to sort through the cruft to
find the critical ones. Being able to ignore an error in the GitLab UI,
gives you the ability to clear out errors that don’t need attention, so
that you can easily focus on the ones that require fixing. Ignoring
non-critical errors makes the error list easy to scan and triage. The
Ignore button can be found on the specific detail page for the error
and on the error list.
Configure default commit message for applied Suggestions
Suggesting changes
in merge requests makes proposing improvements easy. However, if you
use a push rule to require a specific format for all commit messages,
in most cases it wasn’t possible to apply the suggested change, because
the commit message generated by GitLab wouldn’t match the validation
pattern for the push rule.
GitLab 12.7 now supports configuring a commit message template for the
commits created by GitLab when applying a suggested change, so to that
is valid according to your commit message push rule.
Thanks Fabio Huser and Siemens!
Autolink Rust package names
When browsing a project, looking at its dependencies is often useful,
but dependencies are typically stored in machine-generated files that
link to a public package registry.
Now, when viewing a Rust project’s Cargo.toml dependency file, GitLab will
detect and link packages to crates.io, so that it
is easier to understand its dependencies. Previously, in GitLab
9.3
support was added for Go, Ruby, Node.js, Python, PHP, and Objective-C.
Thanks Fabio Huser and Siemens!
Find SSH and deploy keys by MD5 and SHA-256 fingerprint
With OpenSSH switching to SHA-256 by default
in 2015, displaying a MD5
hash for SSH keys is not useful. Thanks to a community contribution,
you’re now able to see the SHA-256 fingerprint for both SSH and deploy
keys - and query
for a user via the key’s fingerprint, thanks to the addition of
this new API.
Thank you to Roger Meier (@bufferoverflow) for the contribution!
Duplicate metrics dashboards
GitLab comes out-of-the-box with a number of useful metrics dashboards for
monitoring your application’s health. In 12.7, you can now easily
duplicate one of those default dashboards in order to make slight
customizations to add, for example, your application’s specific system
or business metrics.
Require all users to log in to access GitLab Pages websites
GitLab Pages now has a way to disable non-authorized access separate
from project privacy settings, which will then require all users to log
in prior to accessing the site even if the project is set to public.
This setting can be enabled by a GitLab administrator via a checkbox in the Admin Settings for Pages.
Surface language and urgency information on Sentry error detail page
Triage of errors is challenging because they are noisy, and pertinent
information is difficult to find. The error detail page in GitLab
surfaces the most important attributes of an error. With GitLab 12.7,
those details now include language and urgency, intended to help
determine the root cause of the error as quickly as possible.
Support for Elasticsearch 7.x
In GitLab 12.7 we’ve updated dependencies across our indexer and GitLab
to support Elasticsearch 7.x alongside our existing support for
Elasticsearch 6.x. This is the most requested
feature
for our Elasticsearch integration so we’re very excited to be including
this in the release.
With the update to support Elasticsearch 7.x we’re also shipping version
2.0.0 of our indexer which officially provides this support. As
previously
mentioned,
Elasticsearch 5.6.x is no longer supported for use with GitLab.
API route for all project services of a project
A new API route is available under /projects/:id/services that
provides a list of all active project services for that given project.
Previously, the GitLab API included routes that allowed for creating,
editing, and deleting services–but no route to get this list.
The ability to get a list of active services makes it easier for
developers to programmatically add and edit services on their projects
from the API.
GitLab Chart improvements
- Documentation was added to provide instructions for connecting GitLab to an external Minio instance for object storage.
- The GitLab chart no longer manages the life cycle of the GitLab operator CRD (Kubernetes Custom Resource Definition). Installation of the CRD now can be done directly with
kubectl. For new instructions on installing CRD, see the GitLab Operator installation docs.
- The flag to disable
gitaly has been moved to a global setting. This simplifies the process for disabling Gitaly so that you no longer need to edit multiple settings across the various services. For new instructions on how to disable Gitaly to leverage an external Gitaly service, see Configure this chart with External Gitaly.
GitLab Runner 12.7
We’re also releasing GitLab Runner 12.7 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.7 are:
Parse and analyze instance activity with structured application logging
GitLab’s log
system allows
administrators to monitor and evaluate log files to better understand
the state of an instance. These logs have a wide variety of use cases,
including performance monitoring, analytics, and system auditing.
Some logs, however, are only offered in an unstructured format — making
them challenging to parse. One of these unstructured logs was
application.log, which recorded application activity including
project, group, and user events. In 12.7, we’ve introduced a more
flexible logging
system in
GitLab, and introduced a JSON-formatted version of application.log in
the form of application_json.log.
Creating a structured version of this logfile opens up a number of
interesting use cases, like ingesting into a monitoring tool for event
auditing, sending these events to a visualization tool to build
customized dashboards, and many more.
Create an issue directly from an epic
No more switching through multiple tabs to create an issue and assign it
to an epic! You can now create an issue directly from the Epic view.
Cut and paste a Markdown table from a spreadsheet
Incorporating tabular data into Markdown can be a tedious and labor
intensive process. As of 12.7, you can now copy content from a
spreadsheet and paste it directly into a Markdown editor within GitLab.
Automatically converting the spreadsheet into valid Markdown
syntax let’s you spend less time formatting and more time creating
amazing things.
Automatically stage all changes in Web IDE
The Web IDE in GitLab is a great tool for contributing changes to a
project. However, the lack of a persistent file system can become a
challenge. Situations may occur where users make changes to multiple
files, but not all changes are staged and committed prior to browsing
away from the Web IDE page. This could result in the loss of
those changes.
In order to make the Web IDE more accessible to users and prevent more
cases of accidental loss, changes in the Web IDE will now be
automatically staged. When a user clicks Commit, the following
commit screen will give them the ability to add their commit message and
select their branch instead of giving the option to stage changes.
Delete a pipeline from the UI
Previously, deleting a pipeline was only possible from the API. As of
12.7 users with owner permissions to a project can click on the new
Delete button to delete a specific pipeline directly from the
Pipeline Details page. This non-reversible action expires the pipeline
caches and deletes all related objects (builds, logs, artifacts, and
triggers).
A key benefit of being able to delete a pipeline from the UI is the
ability to take immediate actions to protect leaked secrets if a job in
the pipeline exposes private keys in plain text. And an even more commom
use case for deleting pipelines is the need to clean-up a messy CI history
littered with failed pipelines resulting from CI configuration attempts or
experiments; a side benefit of cleanup being assurance that undesirable
pipelines are not inadvertently used again.
Zoom in on your Designs when viewing them
When uploading a large image, like a widescreen website layout, to the Designs tab in an issue, there
was difficulty in seeing the detail of the image because it was
displayed in the fixed-width viewport. We now include the ability to
zoom in on the Design so you can get into the details! You’ll find the
zoom controls at the bottom of the image.
Auto DevOps does not run unless Dockerfile or matching buildpack exists
Auto DevOps is a great way to get started with modern DevOps practices
for any project. However, until now, Auto DevOps needed to run a CI
pipeline to determine compatibility with a project by checking if an
existing Dockerfile or a matching buildpack exists for the project.
In an effort to make it more efficient and taking advantage of the new
workflow:rules
feature in GitLab CI, Auto DevOps will only run if the project contains
a Dockerfile or if a matching buildpack exists for the project’s
language.
Install Kubernetes applications using CI templates
Installing Kubernetes applications using GitLab
CI
provides a great way to customize Helm charts and custom resources
(CRDs) prior to installation. As part of this release we have added
templates for installing
Cert-Manager
as well as
GitLab Runner
using GitLab CI. Installing the GitLab Runner helm chart via GitLab CI
allows users to configure settings they previously could not, such as number of
concurrent jobs or the jobs check interval.
Create templates for email responses from the Service Desk
Service Desk email responses can now be customized per your
organization! Simply add template Markdown files to your repository and
when the Service Desk responds to a user, the templates are used! This
will allow custom branding and messaging to provide an optimal
experience for customers.
Geo supports replicating Design Management assets
GitLab Design
Management
allows users to upload design assets (e.g. mockups) to GitLab issues and
store them in one place.
GitLab Geo now supports replicating these Design Management assets to
secondary nodes, ensuring that distributed teams can access them from
the closest Geo node. Because Design Management assets are replicated,
they can also be restored from a secondary node.
We currently don’t support
verification
of these assets and will add support in a future release.
Append user template to incoming Service Desk issues
The Service Desk allows new issues to be created by sending an email to
a unique address. When these new Service Desk issues are created, it would be beneficial if they
could be automatically assigned to a specific user, given a label or
assigned to a milestone. You can now do that by creating a template to
be included with all new Service Desk issues. Include any of the quick
actions in the
template and they will activate when the issue is created.
Appearance API
You’re now able to adjust appearance settings of your instance -
including attributes like your instance’s title, description, favicon,
logo, and others - through a new API.
Thank you to Fabio Huser and Siemens for the
contribution!
Link to GitLab commit on the Sentry error detail page
Digging through a stack trace is cumbersome enough without also having
to determine what version impacted the affected file. In GitLab 12.7,
the commit that most likely caused the error is automatically surfaced
on the error detail page. Being able to automatically associate the
commit with the suspect error you are seeing can significantly reduce
the time to resolve the error. This gives you the ability to immediately
roll back the change, or fix it with a patch.
Please note that in order to take advantage of this feature, you will
need to name your Sentry Release objects with the SHA of the deployed
commit.
Improved diff highlighting for Merge Request Suggestions
Proposing improvements to a Merge Request using a Suggested Change
makes collaborating easier by applying the change and resolving the
discussion with a single click.
In GitLab 12.7, improved diff highlighting of suggested changes makes
it obvious which words and characters have changed, so that you can
apply the suggestion with confidence.
Disable automatic closing of Issues from Merge Requests
Every team has unique needs. Oftentimes, it’s necessary to keep an
Issue open beyond the life-cycle of a single Merge Request or to
reference an Issue in a commit without the intent of closing the Issue.
Prior to this release, teams did not have a way to disable the default
behavior of automatically closing an Issue by mentioning it in a Merge
Request or commit. As a step towards providing teams with more granular
control over this functionality, you can now disable automatic closing
of Issues within your Project’s settings.
Thanks Fabio Huser and the Siemens crew!
Resolve Sentry errors in GitLab
Once you’ve identified the root cause of an error, deployed the fix, and
verified its success (all from within GitLab). With GitLab 12.7, it is
now possible to resolve the error without switching to Sentry, just with
a click of a button. The Resolve button can be found on the specific
detail page for the error.
Improved initial response time of /projects API endpoint
In GitLab 12.7, we have made stark improvements to the first page
response time of the /projects API. Previously, for some parameter
combinations, we were seeing response times as high as 30 seconds on
GitLab.com. With these changes, the majority of responses will be within
one second. Note that these improvements apply regardless of the
pagination strategy used.
Faster /projects API endpoint with keyset pagination
We have introduced a new paginaton mechanism for the /projects API
endpoint. Previously, offset-based
pagination was
the only method available, which while providing flexible sorting and
filtering options, performs increasingly poorly for each page requested.
This poor performance characteristic put increasing loads on the GitLab
server, and also exhibited longer and longer response times.
With GitLab 12.7, we are introducing keyset-based
pagination.
While this method only allows for sorting based on project id, it
performs significantly faster with consistently low response times
regardless of which page you are requesting. Utilization of keyset
pagination for queries which retrieve many pages, will both reduce the
load on the GitLab server and result in faster data retrieval.
In 13.0, we will implement a configurable page depth
limit for
offset-based pagination, defaulting to a maximum depth of 50,000
records. This limit of 50,000 will be enforced on GitLab.com in 13.0.
Allow CI to be skipped on rebase when using API
It was already possible to skip the creation of a CI pipeline when using
ci skip (or skip ci) in your commit
message or by using
push
options,
but it was not possible to skip CI when rebasing. As of 12.7 it is now
possible to do so when using the rebase API.
GitLab Chart 3.0 released
GitLab Chart 3.0, released along with GitLab 12.7, is a new major
version of the GitLab Helm chart. Due to the significant changes in this
version, upgrading requires additional steps to be performed and should
be done in accordance with the upgrade
documentation. GitLab
Chart 3.0 includes functional improvements and updates to a number of
components, each of which are outlined below and linked to the GitLab
Chart 3.0 epic.
- The GitLab Chart uses a fork of the nginx-ingress chart. GitLab Chart 3.0 pulls in changes that were made in the upstream nginx-ingress chart to ensure GitLab compatibility with Helm 2.15.0 and Helm 3.
- The
extensions/* and apps/beta* API versions stopped being supported in Kubernetes 1.16. Multiple upstream charts used by GitLab have been updated to stop using these API versions. GitLab chart 3.0 includes updated upstream charts: Prometheus chart 9.4.x, PostgreSQL chart 7.7.0, and Redis chart 10.3.x (no longer forked).
- Sidekiq deployments now use unique selectors to avoid confusion over which deployments own a set of sidekiq pods when multiple deployments are created. For important information about upgrading Sidekiq deployments, refer to the upgrade documentation.
Omnibus improvements
- The version of Redis bundled in Omnibus GitLab has been updated from Redis 3.2.12 to Redis 5.0.7, which brings GitLab up to date with the latest stable release of Redis. Redis 5 includes a number of improvements. For more information on the changes made in Redis 5, see the Redis release announcement. A manual restart of Redis is required after upgrading. See the upgrade notes for instructions, and additional details for Redis HA.
- Upgrades between certain versions can sometimes fail if background migrations are still running when the upgrade is attempted. Documentation has been added to Updating GitLab that explains how to check whether background migrations are still running.
- The Ruby version included in GitLab has been updated from 2.6.3 to 2.6.5 to include some fixes and security patches.
- Documentation was added on how to use the
EXTERNAL_URL environment variable to make it easier to get a GitLab instance up and running.
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