Puma support is currently experimental, while we work to enable Puma by default in 13.0. You can try it on a test system today , and report any issues here .

In order to reduce the memory requirements of GitLab, we are migrating to Puma from Unicorn . Puma supports multi-threading, which can reduce the memory footprint of GitLab by about 30%.

This is particularly valuable when you are trying to troubleshoot a failing integration, as previously there was no place in the UI directly where these errors were displayed. Now, you’ll have easy access to understand what has failed (or is currently working!) and why.

To assist users in troubleshooting CI integrations, we’ve added a log of recent events to the integration configuration pages. This log is available on the integrations settings pages for Jenkins, Packagist, Team City, DroneCI, Buildkite, and Bamboo. This new section lists the events that have triggered this integration in the last two days.

Projects that have dependencies that are hosted in a private repository now have a way of propagating authentication credentials for the private repository into the SAST container to have them used by the analyzing command.

Kubernetes manifests can now be checked for sensitive data like secrets and privileges, by using kubesec .

If you are using PHP in your project, you can now use our License Compliance feature. Please note this is at the experimental support level. We added support for PHP, specifically focusing on composer-based projects (using composer.lock ).

Errors are often plentiful, noisy, and challenging to dig through to find the important ones which are impacting your users. Starting in GitLab 12.6, as you view a list of Sentry errors in GitLab, you’ll be able to sort those errors based on frequency and when an error was last and first seen.

You’ve been there. You are troubleshooting an error you found in your application and have to frequently jump back and forth between searches through your error list. Starting in GitLab 12.6, you’ll be able to quickly select recent searches when filtering errors.

Starting with GitLab 12.6, when you install Knative as a GitLab Managed App, version 0.9 will be installed. This is a major upgrade in the life of Knative. Knative Serving has received its final v1 API endpoints and is considered to be production ready, but the beta and alpha endpoints are still available. Given the stable API, this upgrade provides some level of forward-compatibility too.

Note: We announced Cloud Run for Anthos support in GitLab 12.4, however we had to switch it off later due to compatibility issues. We’ve been working hard to ship a future-proof integration.

When creating a Kubernetes cluster via GitLab’s GKE integration, users can now optionally enable “Cloud Run on Anthos” with a single click. GKE will automatically provision the cluster with Knative serving, Istio, and HTTP load balancing, and Cloud Run will take care of keeping the cluster upgraded. When installed, users can continue to take advantage of the features offered by GitLab Serverless to deploy Knative services with minimal configuration.

Auto DevOps’ Auto-Deploy now allows for bulk configuration of its Helm chart values. By simply adding a .gitlab/auto-deploy-values.yaml file to your project, Auto DevOps will automatically detect it and use its values for deployment. This eliminates the need to create multiple HELM_UPGRADE_EXTRA_ARGS environment variables for your project and has the added benefit of version control.

GitLab now provides the ability to remove all the related cluster resources upon removal, making it fast and easy to re-use clusters elsewhere.

Re-using clusters across instances, groups, or projects can be time consuming as operators must ensure that all related cluster resources (such as namespaces, roles, bindings, etc.) are removed from the cluster prior to linking it to a new entity. Often times, operators choose to destroy a cluster and create a new one to avoid manual deletion of resources.

You can now define different userID targets for your feature flags per environment. The value that is gained here is that with this combination you can target different users on production than staging (or others) which allows you total control on how, where and to whom your Feature Flag will be toggled.

In GitLab 12.6, we are adding the capability to edit Release titles and notes directly from the user interface, instead of using the GitLab API. This provides a faster and more intuitive method to edit releases.

In GitLab 12.6, we are excited to announce a new API endpoint that will allow users to list all packages at the group level.

As part of the GitLab Package Registry, we provide an API , to allow users to view, download, and delete packages. However, until recently the API was limited to a specific project, which prevented users from understanding which packages exist at the group level.

When using a mix of project & group variables, it can be confusing to understand what group variables exist and how they may be related or conflict with project level variables. We have improved this by now showing the group (inherited) variables in the project variables page, making it easy to see what variables are coming from where.

In GitLab 12.6, we simplified usage of the tool by removing the need to create a personal access token to provide feedback.

In GitLab 12.0, we introduced Visual Review Tools to allow users to provide feedback on merge requests from the Review App itself.

Before clicking Merge, if you make a final tiny fix by pushing or applying a suggestion, the merge button is disabled until you reload the page. This slows down the final stages of review when applying the final fixes. In GitLab 12.6, the merge request widget is now updated in real-time so that you can merge immediately or when the pipeline succeeds.

In GitLab 12.1, we introduced fork de-duplication for public projects, but many organizations missed out on the benefits because they primarily use internal projects. In GitLab 12.6, creating a fork of public or internal projects creates an object pool (if one doesn’t already exist) and uses objects/info/alternates to reduce the storage requirements of forks.

Forking workflows makes it easy to contribute to any project by creating a copy of the upstream project to work on before opening a merge request to merge your changes into the upstream project. For popular projects, the server-side storage requirements needed for thousands of copies accumulate quickly and increase hosting costs.

Mentioning a group with a large number of members can quickly lead to a high volume of unwanted notifications. To avoid this, you can now enable a group-level setting to prevent members from receiving notifications when the group is mentioned in an issue or merge request.

To reduce this risk, GitLab 12.6 introduces soft deletion for projects. Instead of immediate removal of the project or group, the resource will be marked for deletion and removed after a configurable soft deletion time-frame. While the default time-frame is 7 days, instances wishing to retain immediate deletion can set this to 0.

Currently, deleting a project in GitLab through the UI or API is immediate, irreversible, and unrecoverable without restoring from a backup. This has the potential to result in unintentional data loss, which is a worst-case scenario for the team.

With this change, an instance administrator can configure a maximum lifetime for generated personal access tokens. Applying a limit will expire existing tokens, which must be regenerated and adhere to the newly applied expiration requirement. After a token’s expiration date has passed, it must be regenerated.

Security-minded organizations have historically used regular rotation of credentials to limit the amount of time an attacker has access to a system through a compromised secret. While guidelines from organizations like NIST no longer recommend periodic rotation, we’re adding the ability to enforce regular rotation of personal access tokens due to their inherent lack of 2FA protection, customer demand, and importance in certain compliance frameworks (e.g. PCI ).

Using NIST’s guidance, GitLab is introducing a new setting within the Admin Area to specify a minimum password length that applies only to new passwords. This means any new account being created or any password being changed will be required to meet this minimum length requirement. By enabling customers to define a minimum password length, GitLab environments can become more secure and organizations can manage this policy across an instance for reassurance that passwords are compliant with internal policies.

Organizations need a way to secure their GitLab instances that aligns with their internal policies and procedures. Part of securing GitLab is enforcing a password policy. GitLab recently updated its own internal password policy guidelines based on NIST SP 800-63B . In this special publication, NIST advises on leveraging password length and complexity, but does not recommend password rotation or even requiring specific complexity rules (e.g. a specific number of special characters).

Simplify user management with Personal Access Token and SSH key inventory CORE STARTER PREMIUM ULTIMATE FREE BRONZE SILVER GOLD As your GitLab self-managed instance grows, so too does your need for compliance controls. As more users, groups, subgroups, and projects are added, your instance becomes inherently more complex. You need visibility into who has access to your instance in an aggregate view in order to manage your instance’s risks and compliance. To support customers in this effort, we’ve introduced an MVC for an inventory of PAT and SSH credentials. This view provides important details to administrators, such as the owner, type, and scope of each credential. It will also show when a credential is set to expire and when it was last used. Documentation Issue

ConvDev Index is now DevOps Score CORE STARTER PREMIUM ULTIMATE FREE BRONZE SILVER GOLD As we invest further in analytics in GitLab, our features should align with commonly used terms. Conversational development is a useful concept, but GitLab is built around the language of DevOps. Directly referencing this term is especially helpful for organizations looking to track their adoption of DevOps best practices. We plan on iterating on this feature further, but a first important step is a name change to reflect where we’re going. Documentation Issue

Preview OpenAPI specifications CORE STARTER PREMIUM ULTIMATE FREE BRONZE SILVER GOLD The OpenAPI (previously known as Swagger) Specification is a popular standard for defining RESTful interfaces. However, reading the YAML source can be difficult. In GitLab 12.6, when viewing an openapi.yml file (or another supported filename), a rendered preview of the specification will be shown using the same interface as Swagger. Thank you Roger Meier and Siemens for your contribution! Documentation Issue

More easily navigate between tabs within Merge Requests CORE STARTER PREMIUM ULTIMATE FREE BRONZE SILVER GOLD Merge Requests are where source code is reviewed, tested, and discussed, but they can become unwieldy. Together, merge request descriptions, pipelines, and security scanning results often push the navigation tabs far down the page making them hard to find and difficult to access. In GitLab 12.6, the merge request navigation is now above the description, making it fast and easy to jump directly to the changes. Additionally, the description and widgets are now displayed on the Overview tab, providing improved focus and navigation throughout the merge request. Please share your feedback here. Documentation Issue

Remove fork relationship when project visibility is restricted CORE STARTER PREMIUM ULTIMATE FREE BRONZE SILVER GOLD Forking workflows makes it easy to contribute to any project by creating a copy of the upstream project to work on before opening a merge request to merge your changes into the upstream project. Previously, when the visibility of the root project in a fork network was changed to be restricted, the visibility of all the forks would be restricted. This could result in all forks of a public project suddenly becoming private if the root project was made private. In GitLab 12.6, instead of changing the visibility of all projects, the root project is simply removed from the fork network leaving all other projects unmodified. This is equivalent to the root project being deleted. Documentation Issue

CI configuration outside of the repository CORE STARTER PREMIUM ULTIMATE FREE BRONZE SILVER GOLD We have added the ability to specify the path of the .gitlab-ci.yml to an arbitrary URL, which allows you to store CI configurations in a repository other than the one being built. This can be very helpful for processing many repos the same way by pointing all of them to the same external .gitlab-ci.yml file. Efficiency is gained by having only one CI configuration file to update instead of maintaining individual configurations in each repository. Users that have a service that generates the configuration file dynamically would also benefit. This also makes it possible to protect configurations from unauthorized changes as the file can be hosted in a project with more fine-grained access control. We have updated our documentation to make it clear how to set this up. Documentation Issue

Warning for skipping Merge Trains CORE STARTER PREMIUM ULTIMATE FREE BRONZE SILVER GOLD When users choose Merge Immediately for their merge request, this delays all the merge requests in the Merge Train. Users were unintentionally doing this, unaware of the negative effect caused to the rest of the merge requests. Although we still allow urgent merge requests to skip the line, we added a warning as another layer of protection by explaining that this action will negatively impact others. Documentation Issue

Customize Kubernetes namespace per environment CORE STARTER PREMIUM ULTIMATE FREE BRONZE SILVER GOLD When you use GitLab’s Kubernetes integration, it automatically creates a namespace to serve as a deploy target for GitLab CI/CD. This makes it easy to get started with Kubernetes. However, if you already have a cluster with an existing set of namespaces, more than likely you will want to designate one of those existing namespaces as a GitLab deploy target. Now with GitLab 12.6, you are able to specify a custom namespace for each CI environment in your .gitlab-ci.yml file allowing you to deploy to namespaces that existed before you connected your Kubernetes cluster to GitLab. Initially, this feature is only available for non-managed clusters but does support dynamic environments (e.g. for use in review apps). Documentation Issue

Allow clearing of cluster cache to avoid getting out of sync CORE STARTER PREMIUM ULTIMATE FREE BRONZE SILVER GOLD We often need to carry out actions on Kubernetes clusters directly, for example while troubleshooting or fine tuning. Making changes to Kubernetes resources directly in the cluster can put GitLab out of sync with the cluster so it won’t recreate resources because it assumes they already exist. Starting with GitLab 12.6, the Kubernetes integration will offer the option to clear the local cache of namespace and service accounts, allowing the next CI job to re-create them when necessary. Documentation Issue

Improved integration between Error Tracking and Issue management CORE STARTER PREMIUM ULTIMATE FREE BRONZE SILVER GOLD Triaging errors can be a manual and tedious process often completed by multiple individuals on your team. One team member may determine the Error is critical and go to create issues to fix the error. Starting in GitLab 12.6, Errors provide a link to open issues directly within the Error detail page, eliminating any confusion about whether an issue needs to be created. If an issue doesn’t exist, you can now quickly create a GitLab issue from an generated Error when viewing that Error’s detail page. Documentation Issue

Add Sentry as a GitLab Managed App CORE STARTER PREMIUM ULTIMATE FREE BRONZE SILVER GOLD If you’re a user of GitLab’s Error Tracking features, you value the ability to integrate with Sentry, the most popular open-source error tracking tool. Starting in GitLab 12.6, if you are unable to utilize a Sentry project on Sentry.io, you can deploy Sentry directly to a Kubernetes Cluster attached to your project or group. This will make it much quicker to get started with integrated error tracking in GitLab. Documentation Issue

Access Pod Logs Directly from the Operations Tab CORE STARTER PREMIUM ULTIMATE FREE BRONZE SILVER GOLD Previously, there wasn’t an easy way to navigate directly to your pods’ logs view. In order to get to them you had to navigate to your project’s Environments tab underneath Operations, select the desired environment, and click the relevant pod. Now, with GitLab 12.6, viewing Pod Logs is easier than ever! Simply click on the Pod Logs tab underneath Operations. Documentation Issue Epic

Dependency Scanning improvement for Python projects CORE STARTER PREMIUM ULTIMATE FREE BRONZE SILVER GOLD If your Python dependencies are stored in a file other than the regular requirements.txt , with GitLab 12.6, you can now set the requirements file with the PIP_REQUIREMENTS_FILE variable. Documentation Issue

SAST Support for React framework (JavaScript) CORE STARTER PREMIUM ULTIMATE FREE BRONZE SILVER GOLD If you have projects written using the React framework for JavaScript, you can now use our SAST scanners to find any security issues. Documentation Issue

Dependency scanning for Scala projects using the sbt package manager CORE STARTER PREMIUM ULTIMATE FREE BRONZE SILVER GOLD With GitLab 12.6, we have added support for Scala with the sbt package manager in Dependency Scanning. You are now able to scan your Scala projects for potential vulnerabilities. Documentation Issue

Group Webhooks are now editable CORE STARTER PREMIUM ULTIMATE FREE BRONZE SILVER GOLD Group Webhooks are now editable! Previously, it was only possible to create and delete them, so making a change to a webhook required you to delete the webhook and start over. This addition adds the ability to edit these in the UI, saving you time and effort when setting up your webhooks. Documentation Issue Merge Request