GitLab 13.9 released with a Security Alert Dashboard and Maintenance Mode
GitLab 13.9 is now available to strengthen DevSecOps at scale, with a Security Alert Dashboard to triage high priority alerts, Maintenance Mode for unfailing support of distributed teams, better visibility including additional support for DORA metrics, and advanced automation capabilities that will help you deliver “better products, faster.” These are just a few of the 60+ significant new features and improvements in this release.
DevSecOps at scale
Keeping a production environment both secure and available are top priorities, but they can be difficult to balance. Our new Security Alert Dashboard will help you balance security and reliability, by discerning between suspicious network activity that needs to be blocked immediately or that only needs further attention, minimizing disruption to users. We're also excited to add JavaScript and Python support for coverage-guided fuzz testing, making it easier to build secure and reliable software, with results piped into your Security Dashboard.
GitLab is built for distributed teams. Our new Maintenance Mode enables read-only availability of your instance during more admin tasks, further reducing downtime. Scale and redundancy in data storage are improved with variable Gitaly replication factors, so you can tune your cluster to your own storage and budget constraints, while also enabling horizontal scaling.
Visibility is another core requirement in scaling DevOps, and Release Analytics at the group level continues to grow our support of DORA metrics, now aggregated for projects in a group. The new failed-test counter in Unit Test Reports and a new merge request metric, mean time to merge help you achieve and understand underlying efficiencies.
Automate your way to better products, faster
If you’re new to DevOps or renewing stalled efforts, an edict to deliver “better products, faster” can sound a little like “doing more, with less;” it may feel counterintuitive. But DevOps is the answer and automation is the key to doing both well.
One sure way to build and test faster is to look for redundancies in configuration. A new function in 13.9 saves you time by enabling reuse in your pipeline of a CI/CD configuration from any job, even if it's in another file.
Automating at scale often requires mitigating complexity. When you’ve broken down your pipeline configuration into many files, you’ll like that you can now view an expanded version of the configuration. Deployment processes using parent-child or multi-project pipelines can also now use resource groups to manage concurrency across stages, jobs, and even projects.
Wider community contribution highlights
We’re thrilled to introduce GPU and smart scheduling support for GitLab Runner, supporting specialized compute workloads like those in machine learning, and contributed by this month's MVP, Andreas Gravgaard Andersen! Andreas showed awesome perseverance through reviews that spanned 10 months.
Thanks to another brilliant contribution, you can now follow other GitLab users’ activity! You might start by following its contributor, Roger Meier @bufferoverflow from Siemens, himself a GitLab Hall of Famer and sage of Open Source and InnerSource.
Thank you to Marshall Cottrell @marshall007 from NASA for creating a 1-liner installer for the GitLab Kubernetes Agent and simplifying its configuration, enabling users to get started with the Agent much more easily. Marshall's feedback, ideas, and collaboration beyond merged contributions were also called "invaluable."
Thank you to Kev @KevSlashNull of SiegeGG, who added an Activity filter to Vulnerability Reports, helping you drill into precisely the vulnerability list view you need. GitLab's own AppSec team are grateful as are many others, for this and Kev's many contributions.
GitLab isn't only a DevOps platform, or a company, we're also a community, and in 13.9 alone we enjoyed an incredible 299 merged wider community contributions. Selecting one MVP wasn't easy; thank you all for your professionalism and hard work.
And so much more!
Some of our favorite quality of life improvements in 13.9 include:
- Create changelogs using the GitLab API
- Mark changes as viewed in merge requests
- Request a follow-up review from a Reviewer
- Create Jira issues from Vulnerabilities
- Assign incidents to milestones
- Markdown links for Feature Flags
- Allow Deploy Keys to push to protected branches
Read on for more, and to preview what's coming in next month’s release, check out our Upcoming Releases page and our 13.10 release kickoff video.
Join us for The Total Economic Impact™ of GitLab
This month's Most Valuable Person (MVP) is Andreas Gravgaard Andersen
In 13.9, Andreas added Graphical Processing Unit (GPU) support in GitLab Runner. This change enables you to train machine learning models, render animations, or offload other calculations. For more details, see the item below. This merge request finally landed for 13.9 thanks to Andreas’ persistence and responsiveness to many rounds of reviews spanning over 10 months. Thank you Andreas! 🙌
Security Alert Dashboard for Container Network Policy Alerts
We’re pleased to announce the first release of a dashboard for security alerts! Users can now configure Container Network Policies to send alerts to the security alert dashboard. This is especially useful when traffic must be closely monitored but cannot be blocked entirely without negatively impacting the business. You can configure the alerts at Security & Compliance > Threat Management > Policies, and view them at Security & Compliance > Threat Management > Alerts.
Maintenance Mode
Systems administrators occasionally perform maintenance operations on their GitLab instance to keep it performing optimally. Administrators want to offer the highest level of access to their users while these operations are taking place. For example, you may want to perform a failover test to a secondary site as part of the company’s business continuity plan. Prior to the failover, you want to pause changes for a short period to ensure the secondary is fully synchronized. Until GitLab 13.8, you could restrict users from logging in, but this would block the entire UI and would render GitLab inaccessible to users.
GitLab 13.9 introduces maintenance mode, where write operations are disabled at the application level. This means that GitLab is effectively in a read-only state for all non-administrative users (administrators are still able to edit application settings and background jobs continue). Regular users are able to log in to GitLab, view the interface and perform other read-only operations, such as git clone or git pull. Using maintenance mode, systems administrators can perform maintenance operations, such as failing over to a secondary site, with minimal disruption to regular users.
Note that GitLab already supports zero-downtime updates and enabling maintenance mode is not required to keep your instance up-to-date.
Release Analytics at the group level
In GitLab 13.9, you can view group-level release analytics. This provides you with an aggregated view of all release metrics for each of the projects associated to that group. You can view how many releases belong to this group and what percent of the projects are associated with releases. This feature also serves as a first iteration towards supporting DORA 4 metrics at the group level.
JavaScript and Python support for coverage-guided fuzz testing
You can now run coverage-guided fuzz tests against your Python and JavaScript apps! These are two of the most popular languages and we’re excited to support them for use in coverage-guided fuzz testing.
To run fuzz tests against apps written in these languages, use the same workflow you would for any other supported language. Create a fuzz testing job to run in your pipeline. When GitLab runs it, any fuzzing results automatically appear in the the Security Dashboard, and in the Security tab of the pipeline.
Override Gitaly Cluster replication factor for specific repositories
Previously, the replication factor of a Gitaly Cluster was the number of nodes in the cluster. This made it impossible to enable Gitaly Cluster for GitLab instances with very large storage requirements. For example, a 500 TB cluster with 50 nodes would require 25 PB of storage space to be provisioned. To enable Gitaly Cluster to be used for instances with large storage requirements, a way was needed to specify a replication factor less than the total number of nodes in the cluster.
In GitLab 13.9, the replication factor for each repository can be set individually to any number less than the number of nodes in the cluster. This allows for replication of only the most important or active repositories, leaving other less critical repositories on a smaller number of nodes. This will allow organizations to tune their clusters to their own storage and budget constraints. We have also enabled a method to configure a default replication factor for all newly created repositories. This should provide users the necessary means to horizontally scale their Gitaly Cluster.
Easily see repeat failed tests in Unit Test Reports
When you are reviewing failed tests in a pipeline, it’s difficult to tell if a failing test is a legitimate failure that needs investigation or a flaky test that will pass on the next execution.
The next iteration of the repeat failed test counter adds the repeat failed test counter to the unit test report. Now you can see how often a test has failed on the default branch without needing a merge request associated with the test execution.
Select CI/CD configuration from any job and reuse it
Previously, if you wanted to reuse the same configuration in multiple jobs, you had two options: add YAML anchors, which don’t work across different configuration files, or use extends to reuse an entire section.
In this release, we’ve added a new YAML function called !reference, which lets you target the exact configuration you want to reuse as part of your CI/CD pipeline, even if it’s in another file.
View an expanded version of the CI/CD configuration
When configuring pipelines, you use keywords like include and extends often. These keywords help break down one long pipeline configuration file into multiple files, which increases readability and reduces duplication. Unfortunately, those keywords can make a pipeline configuration hard to follow. In some configurations, a pipeline configuration file can be mostly composed of a list of other included configuration files.
In this release, you can view a version of your pipeline configuration with all of the include and extends configurations merged together. It’s now much easier to understand more complex pipeline flows and simplifies the debugging process.
Resource Group for multi-project and parent-child pipelines
You can now benefit from using resource groups if your deployment process uses child pipelines or multi-project pipelines. Such pipelines may contain multiple stages, multiple jobs, and even span across multiple projects. Resource groups ensure only one downstream deployment pipeline runs at a time so you can deploy safely. Previously, resource_group only supported deployment jobs in the same project.
Follow user activity
GitLab users can now follow other users’ activity in GitLab! Following users helps you to stay updated on activity by team mates and key project contributors. You can follow or unfollow other users from their user profiles. To see their activity go to the top-level Activity view, and select the Followed Users tab.
Thanks to the amazing work from GitLab contributor Roger Meier from Siemens over the past 3 months, this feature is now available in 13.9.
Create Jira issues from Vulnerabilities
Many customers use Jira as their single source of truth for tracking issues and engineering work. When using GitLab for SCM and CI/CD, they can take advantage of our existing integration to pass information from MRs and commits into existing Jira issues. However, until now there has been no way to automatically pass information about vulnerabilities detected by security scanners into Jira. This leaves users who rely on Jira to track work no choice but to manually copy vulnerability information into new Jira issues.
To address this, we’re introducing a new ability to create Jira issues directly from a vulnerability’s details. You will see this as a new option in your existing Jira integration settings. Simply enable the new option and select the desired Jira issue type. Available issue types are pulled automatically based on the currently configured Jira target project. Once enabled, all places in your project where you can create GitLab issues from a vulnerability will instead directly create a Jira issue of the configured type.
Markdown links for Feature Flags
This release adds Markdown linking for Feature Flags. Users can mention [feature_flag:<IID>] in discussions or comments to refer a specific Feature Flag. Click on the generated link to go to that Feature Flag’s edit page. This makes collaboration on Feature Flags much easier and more convenient.
Allow Deploy Keys to push to protected branches
Prior to GitLab 12.0, Deploy Keys with write access could push commits to protected branches. Support for this was removed due to security concerns, but many users still requested it, as they were using it to ensure that only users with Deploy Keys could push to their repositories. It also eliminates the need to use a service user or machine user, which ties up a license for any team that wants to allow Deploy Keys to push to protected branches just for this use case. We are excited to announce that we resolved this issue and now Deploy Keys can push to protected branches once more while abiding by security best practices. By moving towards an isolated permission model for Deploy Keys, users can now select Deploy Keys to link to protected branches directly from the settings page on protected branches.
Request a follow-up review from a Reviewer
Merge request authors receive feedback from reviewers. Often, this feedback needs to be re-reviewed to make sure all issues have been appropriately addressed. As the author of the contribution, you need to communicate the need for a follow-up to your reviewer.
For reviewers who have already reviewed a merge request, you can now request a re-review. This request triggers a To-Do item and email notification to alert the user that you need a follow-up review of your contribution.
Improvements to the GitLab.com for Jira Cloud Application
You can now sync your Jira Cloud project data with GitLab by using the GitLab.com for Jira Cloud application, available on the Atlassian Marketplace. This plugin displays information about your branches, commits, merge requests, deployments, and feature flags in the Jira Development Panel. Use it to see the current status of work in progress, then quickly navigate back to those pages inside of GitLab.
To make these features easier to use, we’ve made significant improvements to the initial setup process over the last few milestones, and now getting your GitLab namespaces connected is easier than ever. To get started, check it out on the Atlassian Marketplace.
Email notifications when PAT / SSH Keys are revoked
Managing your namespace includes ensuring you know who has access and how. To promote the security of Personal Access Tokens (PATs), you should be able to revoke a user’s PAT when appropriate. To support this control, we’ve added a revoke button for self-managed administrators to revoke these credentials as needed. Now you can manage your users’ PATs and SSH keys from the Credential Inventory in a single screen.
Your users will now also receive an email notification when their PAT(s) or SSH key(s) are revoked or deleted by an administrator. These improvements provide more control for you to manage your users’ credentials and also provides transparency to the user so they can take actions to replace their credentials with minimal disruption.
Improve SAML Timeout Experience
When a user’s SAML session for a GitLab.com group reaches the 7 day timeout limit, the user will no longer need to click a confirmation page to renew their session. GitLab will automatically reach out to the Group’s Identity Provider to check for a valid session and extend it as needed. This change improves the group member’s experience and opens the door for decreasing the SAML session timeout in the future.
Manage Project Access Tokens through the API
In GitLab 13.9, we introduced an API to manage project access tokens. API Access for project access tokens enable integration for users that want to control project access tokens provisioning in external systems or through custom automation.
User Busy status in issue and MR sidebar
In 13.8 we added a User Busy indicator to indicate whether coworkers are available for code reviews and other tasks. In this release, we’ve now included the User Busy indicator in the Assignee section of issue and merge request sidebars.
Filter roadmaps by confidentiality
When viewing a roadmap, there used to be no way to hide confidential epics from the main view. This could be frustrating if you wanted to share your roadmap with a public audience.
In this release we’ve updated the search bar filter to include confidentiality. You now have another layer in which you can refine your roadmap.
Show epic comments on user activity feeds
Until now, interacting with epics didn’t add a note to the user’s activity page. This could have caused user to think they weren’t creating, managing or interacting with an epic properly, or may simply have made it more difficult for them to find their recent activity.
As of this release, you’ll be able to view all of your epic activity on the user activity page and in user profiles and use it to track your collaboration on epics.
Autocomplete GitLab CI Variables in VS Code
GitLab CI is fast and highly configurable, but it can be hard to remember all the predefined environment variables, and the wrong typo can make your .gitlab-ci.yml file invalid. To make it easier to configure your GitLab CI pipeline, the 3.11.0 Release of GitLab Workflow provides auto completion for predefined environment variables when editing your .gitlab-ci.yml file.
Tooltips in the auto complete dialog provide information on what the variable can be used for as well as information on supported GitLab and Runner versions. These additional pieces of information really help to ensure your CI configuration will be valid.
Thanks to @KevSlashNull for the contribution!
Mark changes as viewed in merge requests
When reviewing a merge request that changes many files, it is challenging to keep track of which files you have already reviewed. Reviews are inefficient when you’re required to re-review or spend additional time regaining context on each file in the merge request.
Files can now be marked as Viewed in merge requests to help signal to yourself that the file has been reviewed. This change allows reviewers to quickly stay up to speed on what they’ve reviewed and what still needs to be reviewed for the merge request.
View code review comments in VS Code
In a previous release of GitLab Workflow for VS Code it became possible for you to view merge request changes in VS Code. However, seeing the changes proposed by a merge request is only part of reviewing that change and being able to respond to feedback.
With GitLab Workflow 3.10.0, comments provided on changes are now available as part of the diff view. This greatly improves your ability to action feedback provided on your merge request directly in the editor without the additional context switch between VS Code and GitLab.
We’re continuing to expand on Code Review experiences in VS Code. Responding to comments is up next.
GPU and smart scheduling support for GitLab Runner
Specialized compute workloads like those used in machine learning can significantly benefit from access to GPUs. Developers can configure GitLab Runner to leverage GPUs in the Docker executor by forwarding the --gpu flag. You can also use this with recent support in GitLab’s fork of Docker Machine, which allows you to accelerate workloads with attached GPUs. Doing so can help control costs associated with potentially expensive machine configurations.
Group code coverage data graph
Previously released, group code coverage data is an easy way to see current test coverage of the projects in a group and to get raw data for visualization outside of GitLab. Group code coverage data now includes a graph of the average coverage for all of a group’s projects so you can see how test coverage for the group is trending over time at a glance.
Instance configuration to control latest artifacts storage
In the last release, we wanted to improve storage consumption management by adding a project setting to disable keeping the latest artifacts. GitLab recognizes that as a self-managed user, you may want to opt-out for your entire instance, so we have added a one-click option for you to disable keeping the latest artifacts for all your projects.
Automatically authenticate when using the Dependency Proxy
By proxying and caching container images from Docker Hub, the Dependency Proxy helps you to improve the performance of your pipelines. Even though the proxy is intended to be heavily used with CI/CD, to use the feature, you had to add your credentials to the DOCKER_AUTH_CONFIG CI/CD variable or manually run docker login in your pipeline. These solutions worked fine, but when you consider how many .gitlab-ci.yml files that you need to update, it would be better if the GitLab Runner could automatically authenticate for you.
Since the Runner is already able to automatically authenticate with the integrated GitLab Container Registry, we were able to leverage that functionality to help you automatically authenticate with the Dependency Proxy.
Now it’s easier to use the Dependency Proxy to proxy and cache your container images from Docker Hub and start having faster, more reliable builds.
Dependency Scanning support added for sbt 1.3.0
Users with Scala projects using sbt 1.3 and later can now benefit from Dependency Scanning. Previously only sbt versions 1.2 and below were supported.
Improved Android SAST Support
Since GitLab 13.5, we’ve supported mobile SAST via MobSF. We’ve updated this analyzer to version 2.5 which includes many improvements to mobile scanning capabilities for Android. Major improvements include: adding OWASP MSTG mappings for improved vulnerability information, support for Android 10 API 29, xapk support, and National Information Assurance Partnership (NIAP) analysis for Android.
Our Mobile SAST security scanner is still considered experimental and requires enabling experimental features via a CI variable, SAST_EXPERIMENTAL_FEATURES. We expect to remove this requirement in an upcoming GitLab release.
Multi-project support for .NET SAST scanning
GitLab security scans automatically detect code language and run appropriate analyzers. With monorepos, microservices, and multi-project repositories, more than one project can exist within a single GitLab repository. Previously our .NET SAST tool could only detect single projects in repositories. With this release, our .NET SAST analyzer can now intelligently detect multiple solution files (.sln) in .NET projects and report vulnerabilities across them. This will make it easier and more streamlined for users with multi-project .NET repos to leverage our SAST scanning.
Security Configuration page for all users
With SAST and Secret Detection available to all GitLab customers, we wanted to improve the experience for developers enabling available security scans. We have had a guided configuration experience for Ultimate users and have now made a simplified version of this experience available to all users. This new configuration experience makes it easier for developers to understand which security scans are available to them, find relevant documentation, and provide simple enablement tools. With this initial release, we support a button to create a merge request for SAST. In a future release, we will add additional buttons to easily enable other scan types.
Dedicated URL for CI/CD dashboard tabs
In 13.8, we added support for deployment frequency charts under CI/CD Analytics. In this milestone, we added the ability to navigate directly to each of the CI/CD analytics charts by introducing a URL for each tab, making it easy to bookmark this page or send it to additional colleagues to view.
Support PRIVATE-TOKEN to create releases using the Release-CLI
In this milestone, we added the ability to use the release-cli with a PRIVATE-TOKEN as defined in the Create a release API documentation. This enables overriding the user that creates a release, and supports automation by allowing connection of a project-level PRIVATE-TOKEN or by using a bot user account’s PRIVATE-TOKEN.
Vault JWT (JSON Web Token) supports GitLab environments.
To simplify integrations with HashiCorp Vault, we’ve shipped Vault JWT token support. From the launch, you could restrict access based on data in the JWT. This release gives you a new dimension for restricting access to credentials: the environment a job targets.
This release extends the existing Vault JWT token to support environment-based restrictions too. As the environment name could be supplied by the user running the pipeline, we recommend you use the new environment-based restrictions with the already-existing ref_type values for maximum security.
Access Control for Pages is now supported for Kubernetes deployments of GitLab
In GitLab 13.8 initial support for GitLab Pages was introduced for deployments of GitLab on Kubernetes, allowing users to easily deploy static websites.
With the release of GitLab 13.9, Access Control is now supported, optionally restricting access to the pages site to members of the project. All Pages features are now supported in the GitLab Helm chart.
GitLab chart improvements
- Access Control for GitLab Pages is now available for Kubernetes deployments.
- It is now possible to set labels on all objects, such as deployments and horizontal pod autoscalers, in a more configurable manner. A new
common.labelssetting is available for each subchart. - It is now possible to enable proxy protocol support, to support SSH in environments with an upstream proxy that adds the proxy protocol header, such as AWS ELB’s.
redishas been updated to 6.0.10, andgitlab-exporterto v10
Reduced Puma memory consumption on small instances
By default Puma, the web server used by GitLab, uses multiple workers to improve performance. This is important for scaling GitLab but also results in increased memory consumption.
Small instances with few users and limited resources might not require multiple workers. For this use case, GitLab now supports running Puma in single mode, which reduces the memory consumption of the application at rest by around 250 MB.
Check out the list of current limitations. when running Puma in single mode.
Bug fixes
Some of the notable bug fixes in GitLab 13.9 are:
- Opening Admin Settings page results in the 500 error
- Unit test report not populating when filename attribute is not present
- Builds with a dot “.” in their name fails to load test details in the UI
- SAST flawfinder fails in sast CI job with UnicodeDecodeError error
- SAST security-code-scan panics: index out of range error
- Housekeeping is not run on wiki repos, causing performance degradation over time
- Create issue from Vulnerability details - Edited text is discarded
- Description of Vulnerability is empty in GraphQL
- Network policy preview for
deny allshows asallow all - Error “Filenames contained invalid characters” when attaching images to ticket
not_adjacenterror when moving designs around- Bug with roadmaps where epics show up twice in the UI
- When adding sub epic from sub group, wrong epic is added
- Geo: Fix concurrent VerificationBatchWorker jobs
- gitlab-ctl promotion-preflight-checks incorrectly fails with 0%
- UpdatePagesService jobs may cause backup jobs to fail with error ‘directory has vanished’
- Dependency Scanning analyzer was not updating the Vulnerability Database each scan for specific customers. Please read our blog for more details. Impacted customers are:
- Customers with an edited Dependency Scanning template that pins their analyzers to a non-major-only tag (for example gemnasium:2.27.0)
- Customers running in an Offline Environment
- Customers that have a mirror of the analyzer docker registry
- Self-hosted customers with a pull policy of never or if-not-present.
- Resource events created via the issue update API does not follow the
updated_atparam - Project labels API return “404 Label Not Found” if label name contains dot “.”
- Project name to path conversion in API mangles dots
- Iteration reports not scoping correctly
- “List pipeline jobs” GitLab API does not return an information about retired jobs anymore
- Delayed and manual jobs with DAG are not skipped even they need a failed job
Group webhooks for subgroups
GitLab has made it easier for you to build subgroup management automation with a subgroup webhook. This webhook is triggered when a subgroup is created or deleted. Automation can now be built without relying on continuous API calls, which is cumbersome and puts an unnecessary performance load on your GitLab instance.
Improved user experience for the projects member list
Our project members list has been redesigned to help project administrators quickly identify key attributes about their members for more effective user management. It includes more descriptive terminology, a new layout, headers for all columns, tooltips for key data elements, and more!
New merge request metric: mean time to merge
A new metric, mean time to merge (MTTM), is available in project-level merge request analytics. MTTM is the average time from when a merge request (MR) is created, until the time it is merged. By selecting different dates in the date range selector, you can see how your time to merge MRs changes over time and understand whether you are becoming more efficient at reviewing and merging code.
Bulk edit iterations on issues in groups and projects
Instead of having to manually update the iteration on issues one at a time, you can now bulk update iterations from the issue list of a group or project.
Filter roadmaps by milestones
Communicating your strategic plans or reporting on current work in flight requires being able to focus and filter the view of your roadmap. Further refine your roadmap view by filtering the visible epics by milestone.
This feature was behind a feature flag since GitLab 13.7, and now it’s available for everyone.
Apply a suggestion with a custom commit message
Suggesting changes to a merge request makes code review faster and easier by quickly proposing changes and applying the given feedback at a click of a button. However, we had a default commit message for applied suggestions that couldn’t be customized, preventing users from describing the change and eventually violating the project’s commit messages guidelines.
As a result, merge request authors were often forced to squash commits for the whole merge request, or having to manually apply suggestions locally, or going back and rewording the commits after applying the suggestions.
When applying a suggestion you’re now able to write a custom commit message. This allows authors and contributors to accept suggestions and follow commit message best practices for their projects. If no custom commit message is specified the suggestion is committed with a default commit message.
Create changelogs using the GitLab API
Previously, generating a changelog using GitLab was a manual process. Release Managers had to collect all the changes for a given release and then manually add them to a changelog file, which was time-consuming and prone to error. To make this process easier, we have now added an API that will automatically generate a changelog for a given release based on commit history. This enables development teams to better communicate changes to end users by delivering a consistent and comprehensive set of changelogs for every release.
Merge Refs for changes in merge requests
Merge request diffs have been calculated by git diff target...source which compares HEAD of the target with the merge base of target and source. This works well, until changes from the target branch are merged into the source branch, creating a complete mess of the diff.
Merge requests now compare to <default branch> (HEAD) by default when viewing the changes tab of a merge request. This provides a more accurate and up-to-date diff of the changes during your review.
Access webhook pipeline trigger payloads in CI/CD jobs
When triggering a pipeline with a webhook, the webhook’s payload was not accessible from any jobs in the resulting pipeline. In some cases, the payload carries important information that can determine how the triggered pipeline should work. In this release, we’ve added a new predefined variable to capture the webhook payload so you can easily incorporate it within your triggered pipelines.
GitLab Runner 13.9
We’re also releasing GitLab Runner 13.9 today! GitLab Runner is the lightweight, highly-scalable agent that runs your build jobs and sends the results back to a GitLab instance. GitLab Runner works in conjunction with GitLab CI/CD, the open-source continuous integration service included with GitLab.
What’s new:
- Add support for Nvidia docker runtime to the Kubernetes executor
- Control cache ZIP compression level
- Show artifact/cache upload progress
- Upgrade to PowerShell Core in Windows helper an CI image to 7.1.1
- Enable PowerShell Core support in Docker executor on Linux
- Enable PowerShell Core support in Kubernetes executor
- Automatically authenticate with the Dependency Proxy
- Use configured helper image for updating permissions in Kubernetes executor
- Connect to gitlab instance using self-signed cert with runner on OpenShift
Bug Fixes:
- Gitlab CI script doesn’t pass exit code of previous command properly
- Windows service “shutdown timed out”
- Variable masking issue with repeating characters
- OpenShift Operator-concurrent property of config.toml defined in config map not used
The list of all changes is in the GitLab Runner CHANGELOG.
Install GitLab Runner more easily with in-product help
When you’re not using the shared runners on GitLab.com, getting started with GitLab CI requires installing GitLab Runner and registering the runner to execute jobs in your pipeline. While the GitLab Runner installation process is well-documented, one of our goals is to make it as easy as possible for users to get started with GitLab CI. An initial step on this journey is to release a new GitLab Runner guided install modal window. With this feature, you can select a target platform, copy, and run the install commands without navigating away from the GitLab UI.
Allow or prevent duplicate Maven uploads
You can use the GitLab Package Registry to publish your Java dependencies with Maven or Gradle. By default, you can publish the same package name and version multiple times. This default was chosen based on the behavior of the most common public registries.
However, many of you have expressed that you’d like to prevent duplicate uploads, especially when it comes to releases. We’ve added a new group setting for the Package Registry, and you can now choose whether you’d like to allow or prevent duplicate Maven or Gradle uploads. As mentioned, to match the behavior of the public registries, duplicates will be allowed by default.
You can adjust this setting by using the GitLab API or from the application by navigating to Settings > Packages & Registries. In the coming milestones, we plan to expand this setting for each package manager format and add it to the user interface. Please follow along in the epic or consider contributing a change!
Dependency Scanning now supports npm lock files v2
Users with node projects using npm 7’s lock file version 2 are now supported. Previously, Dependency Scanning would output the following error:[FATA] [Gemnasium] [2020-10-29T19:02:20Z] ▶ Wrong file format version.
Expanded support for Ruby in SAST scans
We want to help developers write better code and worry less about common security mistakes. Static Application Security Testing (SAST) helps prevent security vulnerabilities by allowing developers to easily identify common security issues as code is being contributed and mitigate proactively. We’ve updated our Ruby on Rails SAST analyzer (Brakeman) to a new version (v5) which adds support for most Ruby files, not just Rails projects. This change expands the types of Ruby projects we support and introduces new detection rules. If you have a custom SAST.gitlab-ci.yml file, or override the GitLab SAST brakeman job, you may need to update your CI file to enable this additional scanning.
License Scanning now starts within its stage
Previously, the default behavior was to start License Scanning when the pipeline started. This behavior was unexpected and inconsistent with other GitLab Secure jobs. The default behavior has now been changed so that License Scanning starts when the stage it’s in starts, not when the pipeline starts. If you have customized your .gitlab-ci.yml file and want your License Scanning job to only start when its stage starts, remove the needs: [] statement. If you use the default template and wish to revert the behavior, add the needs: [] statement.
SAST Support for .NET 5
Microsoft’s release of .NET 5.0 is the next major release of .NET Core which supports more types of apps and more platforms than .NET Core or .NET Framework. We have updated our .NET SAST analyzer, Security Code Scan to support this new version which is also now supported with our SAST language detection allowing GitLab SAST to automatically detect .NET 5 projects. This change was part of a community contribution by @shaun.burns.
Vulnerability Report Activity filter
Vulnerability Reports are often the primary way security teams triage and manage vulnerabilities. The current filtering and sorting options provide quick ways to focus the list view on a subset of vulnerabilities for more efficient workflows. You can also see any vulnerabilities that have associated issues or which subsequent scans indicate are resolved. This Activity column indicates at a glance which vulnerabilities might be ready to close out, which are in progress, and which ones might need some attention. However, this column was not one you could filter or sort on!
Now have even more control of your Vulnerability Report experience with the introduction of an Activity filter. Available in the Project, Group, and Security Center Vulnerability Reports, this new filter allows you to view vulnerabilities with issues that are not yet resolved, that are resolved but have no associated issues, that have issues and are resolved, or that have no activity. The available filter options are mutually exclusive sets, allowing you to drill into precisely the vulnerability list view you need for any task.
Keyboard shortcut to toggle between GitLab and GitLab Next
This milestone introduces a keyboard shortcut that toggles between GitLab and GitLab Next. By using the g and x keys, which work from any area of GitLab, you can easily switch between GitLab and GitLab Next. A huge thanks to Yogi for a great community contribution!
ConfigMap support for Kubernetes Agent Server
Users of Kubernetes Agent Server (kas) until now had to use command line arguments to customize their Agent Server installations. This setup proves inadequate for large-scale installations where declarative, repeatable setups are a core part of the workflow, and many arguments need custom settings. With the current GitLab release, the Kubernetes Agent Server helm charts can be installed by custom configs that get merged with the default configurations to make it simple to integrate an Agent Server installation with existing observability and monitoring tools.
Assign incidents to milestones
Not all incidents have the same severity. Many incidents must be immediately addressed to restore the services customers depend on. But some incidents are less critical and can be prioritized against other work and scheduled for a specific release or milestone for implementation. You can now assign low-severity incidents to a milestone from the right sidebar to manage them from your issue boards.
GitLab Exporter uses significantly less memory
GitLab exporter measures various metrics from Redis and the database. We’ve reduced the memory consumption of GitLab exporter by ~60% (~67-71MB) by optimizing its configuration.
This is especially important when running GitLab exporter in memory-constrained environments.
Omnibus improvements
- GitLab’s repository installation script now utilizes CentOS 7 packages for Amazon Linux 2 systems. Existing deployments of GitLab on Amazon Linux 2 can re-run the installation script to update. Note Amazon Linux 2 is not currently officially supported.
redishas been updated to 6.0.10,logrotateto 3.18.0, andlibtiffto 4.2.0- GitLab 13.9 includes Mattermost 5.31.1, an open source Slack-alternative whose newest Extended Support Release offers bug fixes for increased stability and improvements in plugins. This version also includes security updates and upgrade from earlier versions is recommended.
Sort global search results by last updated time
You can choose to sort search results on the GitLab search result page. In GitLab 13.9, we added the ability to sort issues and merge requests results by their last updated time.
Performance improvements
In every release, we continue to make great strides improving GitLab’s performance. We’re committed to making every GitLab instance faster. This includes GitLab.com, an instance with over 1 million users!
In GitLab 13.9, we’re shipping performance improvements for issues, projects, milestones, and much more! Some improvements in GitLab 13.9 are:
Deprecations
Container Scanning Engine Clair
GitLab 14.0 will replace its container scanning engine with Trivy. Currently, GitLab uses the open source Clair engine for container scanning. GitLab 13.9 deprecates Clair. This is not a hard breaking change, as customers who wish to continue to use Clair can do so by setting the CS_MAJOR_VERSION variable to version 3 (or earlier) in their gitlab-ci.yaml file. Since Clair is deprecated, however, note that GitLab will no longer update or maintain that scanning engine beginning in the 14.0 release. We advise customers to use the new default of Trivy beginning in GitLab 14.0 for regular updates and the latest features. Customers can provide feedback and get additional details on our open deprecation issue.
Deprecation date: May 22, 2021
Deprecate Container Registry log formatters
Currently, GitLab supports:
- Text, JSON, and logstash log formatting for app logs.
- Text, JSON, and combined log formatting for access logs.
We will deprecate both logstash and combined, unifying the formatters for both app and access logs with only two options text (for development) and JSON.
Deprecation date: February 22, 2021
Deprecate Container Registry logging hooks
The Container Registry currently supports logging hooks that can only be used for email notifications.
These days, alerts based on log entries are commonly handled by separate tools. As far as we know, none of our users rely on this functionality and it is not used at GitLab either. The implementation of this feature is tightly coupled with the underlying logging library, which is a limitation for our ability to switch dependencies without affecting the available features.
In an effort to simplify the registry features and configurations, we will drop support for logging hooks.
Deprecation date: February 22, 2021
Deprecate Container Registry maxidle and maxactive Redis pool settings
Some of the configuration settings that we currently expose for the Redis connection pool are tied to the underlying Redis client and do not have an equivalent in alternative libraries. As we start working on improving the Redis integration, such as adding support for Sentinel, we decided to start working towards replacing the current Redis client dependency with a more feature-rich alternative that can be better supported. To do this, we need to replace the current Redis pool configuration settings that are tied to the current client library.
We intend to:
- Remove the
redis.pool.maxidleandredis.pool.maxactivesettings. - Add
redis.pool.size(maximum number of connections),redis.pool.minidle(minimum number of idle connections), andredis.pool.maxlifetime(maximum amount of time a connection may be reused) settings.
Deprecation date: February 22, 2021
Deprecate Container Registry support for Bugsnag
Bugsnag is one of the error reporting services supported by the Container Registry. As far as we know, none of our users rely on this service, and at GitLab we use Sentry. In an effort to simplify and consolidate the supported error reporting services, we intend to add support for Sentry and remove support for Bugsnag.
Deprecation date: February 22, 2021
Deprecate Container Registry support for NewRelic
NewRelic is one of the error reporting services supported by the Container Registry. As far as we know, none of our users rely on this service, and at GitLab we use Sentry. In an effort to simplify and consolidate the supported error reporting services, we intend to add support for Sentry and remove support for NewRelic.
Deprecation date: February 22, 2021
Deprecate Container Registry support for TLS 1.0 and 1.1
Support for TLS 1.0 and TLS 1.1 has been deprecated and removed for GitLab for security reasons. We will do the same for the GitLab Container Registry, which currently supports 1.0 (default), 1.1, 1.2, and 1.3. and defaults to 1.0.
We will deprecate support for TLS 1.0 and TLS 1.1, showing a warning log message when these are used. Support for these versions will be removed and TLS 1.2 will become the default.
Deprecation date: February 22, 2021
Deprecate and remove secret_detection_default_branch job
To ensure Secret Detection was scanning both default branches and feature branches we introduced two separate secret detection CI jobs in our managed Secret-Detection.gitlab-ci.yml template. These two CI jobs, secret_detection_default_branch and secret_detection, created confusion and complexity in the CI rules logic. As part of this deprecation, we are moving the rule logic into script which will determine how the secret_detection job is run (historic, on a branch, commits, etc). If you override or maintain custom versions of SAST.gitlab-ci.yml, Secret-Detection.gitlab-ci.yml, you must update your CI templates. We strongly encourage inheriting and overriding our managed CI templates to future proof your CI templates. We will stop supporting the old secret_detection_default_branch job with GitLab 14.0, releasing May 22, 2021.
Deprecation date: March 17, 2021
Deprecate disk source configuration for GitLab Pages
GitLab Pages API-based configuration has been available since GitLab 13.0 and will replace the disk source configuration, which will be removed in GitLab 14.0. We recommend that you move away from using disk source configuration and move to gitlab for an API-based configuration, since disk will no longer be supported and cannot be chosen. You can migrate away from the ‘disk’ source configuration by setting gitlab_pages['domain_config_source'] = "gitlab" in your gitlab.rb/etc/gitlab/gitlab.rb file. We recommend that you do this before GitLab 14.0 so you can find and troubleshoot any potential problems ahead of time.
Deprecation date: May 22, 2021
Deprecate pulls that use v1 of the Docker registry API
GitLab disabled pulls via the Docker registry v1 APIs on January 22, 2021. Deprecated by Docker in June, 2019, deprecating this feature allows the GitLab team to focus on features and fixes that provide you with more value and target current registry use cases.
Existing users of the v1 registry API on GitLab can move to the v2 registry API by completing the following steps:
- Update your Docker Engine to 17.12 or later so it is compatible with the v2 registry API.
- If you have content in GitLab that is in the v1 format, you can move it to the v2 format by using a newer Docker client (more recent than 1.12) to rebuild the image and push it to GitLab.
Deprecation date: February 22, 2021
Deprecating SAST analyzer SAST_GOSEC_CONFIG variable in favor of custom rulesets
With the release of SAST Custom Rulesets in GitLab 13.5 we allow greater flexibility in configuration options for our Go analyzer (GoSec). As a result we no longer plan to support our less flexible SAST_GOSEC_CONFIG analyzer setting. This variable will be deprecated in GitLab 13.10, and removed in GitLab 14.0. If you override or leverage SAST_GOSEC_CONFIG in your CI file, you will need to update your SAST CI configuration or pin to an older version of the GoSec analyzer . We strongly encourage inheriting and overriding our managed CI templates to future proof your CI templates. We will remove the old SAST_GOSEC_CONFIG variable in GitLab 14.0, releasing May 22, 2021.
Deprecation date: March 22, 2021
Deprecation of release description in the Tags API
GitLab 14.0 will remove support for the release description in the Tags API. You’ll no longer be able to add a release description when creating a new tag. You’ll also no longer be able to create or update a release through the Tags API. Please migrate to use the Releases API instead.
Deprecation date: May 22, 2021
Deprecations for Dependency Scanning
Previously to exclude a DS analyzer, you needed to remove it from the default list of analyzers and use that to set the DS_DEFAULT_ANALYZERS variable in your project’s CI template. We determined it should be easier to avoid running a particular analyzer without losing the benefit of newly added analyzers. As a result we ask you to migrate from DS_DEFAULT_ANALYZERS to DS_EXCLUDED_ANALYZERS when it is available. Read about it in issue #287691 or this blog post.
Previously to prevent the Gemnasium analyzers to fetch the advisory database at runtime, you needed to set the GEMNASIUM_DB_UPDATE env variable. Though, this is not documented properly and its naming is inconsistent with the equivalent BUNDLER_AUDIT_UPDATE_DISABLED variable. As a result we ask you to migrate from GEMNASIUM_DB_UPDATE to GEMNASIUM_UPDATE_DISABLED when it is available. Read about it in issue #215483 or this blog post.
Deprecation date: May 22nd, 2021
Fuzz test jobs will fail with allow_failure if vulnerabilities are found
To make sure our fuzz testing jobs behave consistently with each other, as part of 14.0, all fuzz testing jobs will start failing if a job finds vulnerabilities. These jobs will have allow_failure=true set in them so you will get a warning but your pipeline as a whole will not fail if a vulnerability is found.
This is the current behavior for several of the fuzz scanners, such as the Go and C++ fuzz engines.
No action is required on your part to use this new behavior. If you are checking the results of a pipeline fuzz testing job as part of a script, consider if those scripts will need any updates.
Deprecation date: May 22, 2021
Git default branch name change
Every Git repository has an initial branch. It’s the first branch to be created automatically when you create a new repository. By default, this initial branch is named master. Git version 2.31.0 (scheduled for release March 15, 2021) will change the default branch name in Git from master to main. In coordination with the Git project and the broader community, GitLab will be changing the default branch name for new projects on both our SaaS (GitLab.com) and self-managed offerings starting with GitLab 14.0. This will not affect existing projects.
For more information, see the related epic and the Git mailing list discussion.
Deprecation date: Apr 22, 2021
GitLab OAuth implicit grant deprecation
As OAuth 2.1 omits the implicit grant, GitLab will deprecate the OAuth 2 implicit grant flow. Beginning in 14.0, new applications will not be able to be created with the OAuth 2 implicit grant flow. Existing OAuth implicit grant flows will no longer be supported in 14.4. Please migrate existing applications to other supported OAuth2 flows before release 14.4.
Deprecation date: May 22, 2021
GitLab Runner installation to ignore the skel directory
In GitLab Runner 14.0, the installation process will ignore the skel directory by default when creating the user home directory. Refer to issue #4845 for details.
Deprecation date: Jun 22, 2021
Helm v2 support
Helm v2 was officially deprecated in November of 2020, with the stable repository being de-listed from the Helm Hub shortly thereafter. With the release of GitLab 14.0, which will include the 5.0 release of the GitLab Helm chart, Helm v2 will no longer be supported.
The Cloud Native GitLab Helm chart will not immediately be altered to Helm v3’s new schema, but moving forward there are opportunities for improved maintainability we would like to be able to leverage. Deprecating the constraint that functionality be limited to that within Helm v2 allows us to better the experience for our users.
Deprecation date: May 22, 2021
Legacy Feature Flags Deprecation
Legacy Feature Flags became read-only in GitLab 13.4. Support for legacy Feature Flags will be removed in GitLab 14.0. You must migrate your legacy Feature Flags to the new version. You can do this by first taking a screenshot of the legacy flag for tracking. Then delete the flag through the API or UI (you don’t need to alter the code) and create a new Feature Flag with the same name as the legacy flag you deleted. Also, make sure the strategies and environments match the deleted flag. We created a video tutorial to help with this migration.
Deprecation date: May 22, 2021
Limit projects returned in GET /groups/:id/
To improve performance, we will be limiting the number of projects returned from the GET /groups/:id/ API call to 100. To get a complete list of projects, please use the GET /groups/:id/projects API call.
Deprecation date: May 22, 2021
Make pwsh the default shell for newly-registered Windows Runners
In GitLab Runner 13.2, PowerShell Core support was added to the Shell executor. In 14.0, pwsh will be the default shell for newly-registered Windows runners. Windows CMD will still be available as a shell option for Windows runners. Refer to issue #26419 for details.
Deprecation date: Jun 22, 2021
Migrate from SAST_DEFAULT_ANALYZERS to SAST_EXCLUDED_ANALYZERS
Until 13.9, if you wanted to avoid running one particular GitLab SAST analyzer, you needed to remove it from the long string of analyzers in the SAST.gitlab-ci.yml file and use that to set the SAST_DEFAULT_ANALYZERS in your project’s CI file. If you did this, it would exclude you from future new analyzers because this string hard codes the list of analyzers to execute. We avoid this problem by inverting this variable’s logic to exclude, rather than choose default analyzers. Beginning with 13.9, we are migrating to SAST_EXCLUDED_ANALYZERS in our SAST.gitlab-ci.yml file. We encourage anyone who uses a customized SAST configuration in their project CI file to migrate to this new variable. If you have not overridden SAST_DEFAULT_ANALYZERS, no action is needed. SAST_DEFAULT_ANALYZERS will be removed in GitLab 14.0, which will release on April 22, 2021.
Deprecation date: February 22, 2021
Pin Static Analysis analyzers and tools to minor versions
With the maturity of GitLab Secure scanning tools, we’ve needed to add more granularity into the versioning of our SAST analyzers. This change will make it easier for customers to set specifically which version of analyzers they want to run, introducing more control into how customers choose to upgrade their SAST scanning. Prior to 13.10, GitLab shared a major version number for all our SAST analyzers and tools and prevented the use of semantic version numbering for updates.
Beginning in 13.10 GitLab SAST and Secret Detection will start using major.minor version pinning in our .gitlab-ci.yml files and will ship major.minor tags on analyzer containers. We will also deprecate the SAST_ANALYZER_IMAGE_TAG variable in our managed SAST.gitlab-ci.yml CI template in favor of major.minor tags for each analyzer. If you override or maintain custom versions of SAST.gitlab-ci.yml, Secret-Detection.gitlab-ci.yml or rely on analyzer x-y-stable tags, you will want to update your CI templates. We strongly encourage inheriting and overriding our managed CI templates to future proof your CI templates. This change will allow you to instead override with a pinned major.minor version to gain more granular control of future feature updates. We will remove shared major version pinning and the SAST_ANALYZER_IMAGE_TAG variable in our managed SAST.gitlab-ci.yml with GitLab 14.0, releasing May 22, 2021.
Deprecation date: March 22, 2021
PostgreSQL 11 support
PostgreSQL 12 will be the minimum required version in GitLab 14.0. It offers significant improvements to indexing, partitioning, and general performance benefits.
Starting in GitLab 13.7, all new installations default to version 12. From GitLab 13.8, single-node instances are automatically upgraded as well. If you aren’t ready to upgrade, you can opt-out of automatic upgrades.
Multi-node database instances will need to switch from repmgr to Patroni, prior to upgrading with Patroni. Geo secondaries can then be updated and re-synchronized.
Deprecation date: May 22, 2021
Removals for License Compliance
In 13.0, we deprecated the License-Management CI template and renamed it License-Scanning. We have been providing backward compatibility by warning users of the old template to switch. Now in 14.0, we are completely removing the License-Management CI template. Read about it in issue #216261 or this blog post.
Deprecation date: May 22nd, 2021
Remove /usr/lib/gitlab-runner symlink from package
In GitLab Runner 13.3, a symlink was added from /user/lib/gitlab-runner/gitlab-runner to /usr/bin/gitlab-runner. In 14.0, we will remove this symlink and the runner will be installed in /usr/bin/gitlab-runner. Refer to issue #26651 for details.
Deprecation date: Jun 22, 2021
Remove FF_SHELL_EXECUTOR_USE_LEGACY_PROCESS_KILL feature flag
In GitLab Runner 13.1, issue #3376, we introduced sigterm and then sigkill to a process in the Shell executor. We also introduced a new feature flag, FF_SHELL_EXECUTOR_USE_LEGACY_PROCESS_KILL, so you can use the previous process termination sequence. In GitLab Runner 14.0, issue #6413, we will remove the feature flag.
Deprecation date: Jun 22, 2021
Remove FF_USE_GO_CLOUD_WITH_CACHE_ARCHIVER feature flag
In GitLab Runner 14.0, we will remove the FF_USE_GO_CLOUD_WITH_CACHE_ARCHIVER feature flag. Refer to issue #27175 for details.
Deprecation date: Jun 22, 2021
Remove Ubuntu 19.10 (Eoan Ermine) package
Ubuntu 19.10 (Eoan Ermine) reached end of life on Friday, July 17, 2020. In GitLab Runner 14.0, we will remove the Ubuntu 19.10 (Eoan Ermine) from our package distribution. Refer to issue #26036 for details.
Deprecation date: Jun 22, 2021
Remove off peak time mode configuration for Docker Machine autoscaling
In GitLab Runner 13.0, issue #5069, we introduced new timing options for the GitLab Docker Machine executor. In GitLab Runner 14.0, we plan to remove the old configuration option, off peak time mode.
Deprecation date: Jun 22, 2021
Remove success and failure for finished build metric conversion
In GitLab Runner 13.5, we introduced failed and success states for a job. To support Prometheus rules, we chose to convert success/failure to finished for the metric. In 14.0, we will remove the conversion. Refer to issue #26900 for details.
Deprecation date: Jun 22, 2021
Remove support for Windows Server 1903 image
In 14.0, we will remove support for Windows Server 1903 as Microsoft ended support for this version on 2020-08-12. Refer to issue #27551 for details.
Deprecation date: Jun 22, 2021
Remove translation from step_script to build_script in custom executor
In GitLab Runner 13.2 a translation for step_script to build_script was added to the custom executor. In 14.0 the ‘build_script’ stage will be replaced with ‘step_script`. Refer to issue #26426 for details.
Deprecation date: Jun 22, 2021
Renewal of the stable Auto Deploy template in Auto DevOps
In GitLab 14.0, we will renew the Auto Deploy CI template to the latest version. This includes new features, bug fixes, and performance improvements with a dependency on the v2 auto-deploy-image. This latest template is opt-in. Unless you specifically customize Auto DevOps in your project, it uses the stable template with a dependency on the v1 auto-deploy-image.
Since the v1 and v2 versions are not backwards compatible, your project might encounter an unexpected failure if you already have a deployed application. Please follow the upgrade guide to upgrade your environments. You can also start using the latest template today by following the early adoption guide.
Deprecation date: May 22, 2021
Unicorn will be removed in favor of Puma for GitLab self-managed
Unicorn support is deprecated and will be removed in GitLab 14.0. You must migrate to Puma before upgrading to GitLab 14.0.
Deprecation date: May 22, 2021
WIP (work in progress) merge requests term deprecated
We renamed the WIP (work in progress) term for merge requests to “draft”, because it’s more inclusive and self-explanatory. The WIP term is now deprecated. We will support its use through the next major GitLab release (14.0), after which it will be removed.
Deprecation date: May 22, 2021
Removals
Geo Foreign Data Wrapper settings removal in 14.0
As announced in GitLab 13.3, the following configuration settings in /etc/gitlab/gitlab.rb are deprecated and will be removed in 14.0:
geo_secondary['db_fdw']geo_postgresql['fdw_external_user']geo_postgresql['fdw_external_password']gitlab-_rails['geo_migrated_local_files_clean_up_worker_cron']
Removal date: May 22, 2021
Legacy storage removal in 14.0
As announced in GitLab 13.0 legacy storage is deprecated and will be removed in GitLab 14.0.
Before upgrading to GitLab 14.0 you must migrate fully to hashed storage.
Removal date: May 22, 2021
Important notes on upgrading to GitLab 13.9
- Cohorts is a feature available in the Admin Area of self-managed installations of GitLab. It shows how many new users have been added to GitLab, how many of them become active users, and how many of those users continue to use GitLab month over month since being added. In GitLab 13.9, Cohorts has been moved from the Analytics section to the Overview > Users section so that it is discoverable alongside other user metrics.
from GitLab https://ift.tt/37xCTqf #GitLab #DevSecOps
Comments
Post a Comment