12.6

GitLab 12.6 Release

GitLab 12.6 released with Security Scorecard and Release Evidence

GitLab 12.6 released with Security Scorecard, Release Evidence, Conan C/C++ repository, and much more!

A common challenge many development leaders face is having visibility into the overall application security and compliance status of their projects. This month's GitLab release helps you more efficiently monitor the application security and release compliance of your projects.

Security Visibility with Project Security Status

With GitLab 12.6, a new Project Security Status panel shows how projects are ranked according to their security profile. This makes it easier for development leaders to quickly understand which projects may have greater risk and therefore might warrant additional attention to address specific issues.

Streamline Audits with Release Evidence

Almost every enterprise development team is expected to document and demonstrate that each release complies with their organization’s policies, procedures, and controls. Often it means they have a manual processes to save the documentation so that future audits can review the compliance evidence. GitLab 12.6 makes audits and compliance much easier, with a release evidence file in the form of a JSON object that includes links to the milestones and issues that were included in the release, which can help to streamline future audits.

Efficiently Manage and Share C/C++ Resources

Many teams are actively developing new high performance applications in C and C++ and they need the ability to easily store and manage the compiled files and binaries from their projects. GitLab 12.6 now helps teams writing code in C and C++ to manage and share both privately and publicly the binaries from their projects with the popular Conan repository built into GitLab. They can now benefit from having source code, automated GitLab CI pipelines and the resulting packages in the same application which will help improve their overall efficiency and velocity.

And Much More

These are just a few of the highlights in 12.6. Check out the other great updates, such as dependency scanning for Java Gradle projects and support for squash-and-merge within Merge Trains.

Also, registration is open for the next GitLab Commit User Conference in San Francisco, January 14.

Join us for an upcoming event Join us at GitLab Commit Release survey

GitLab MVP badge

MVP This month's Most Valuable Person (MVP) is awarded to Fabio Huser

Fabio contributed several impactful merge requests in 12.6 such as exposing the option to disable group mentions, surfacing the coverage delta on MRs, adding pagination to Project Releases, and building in support for Unify Circuit as a project service.

Thanks Fabio and the rest of the crew from Siemens!

12.6 Key improvements released in GitLab 12.6

Quickly understand your at risk projects with Project Security Grades

Quickly understand your at risk projects with Project Security Grades

We’re excited to announce a new “security grades” feature in Group Security Dashboards. In addition to the existing vulnerabilities list and history, this new panel on the Group Security Dashboard lets you know which projects are most affected/at risk so you can go right to the projects that need the most immediate attention.

The severity of any detected vulnerabilities on a project is used to create a simple A through F letter grade. Projects are grouped by grade, so you can easily see which have no unresolved vulnerabilities (grade A) through to those with at least 1 critical (grade F).

Quickly understand your at risk projects with Project Security Grades

Manage C/C++ packages via Conan within GitLab’s Package Registry

Manage C/C++ packages via Conan within GitLab’s Package Registry

For any development organization, having an easy and secure way to manage dependencies is critical. Package management tools, such as Conan for C/C++ developers, provide a standardized way to share and version control these libraries across projects.

In GitLab 12.6, we are proud to offer Conan repositories built directly into GitLab. Developers can now publish their packaged libraries to their project’s Conan repository. Simply set the Conan remote to the GitLab Package Registry and start uploading, installing, and deleting packages today.

Manage C/C++ packages via Conan within GitLab's Package Registry

Filter issues and merge requests by Release

Filter issues and merge requests by Release

Planning and managing a release can be complicated and being able to quickly find the related issues and merge requests makes it easier for teams to manage their work. In 12.6, we have added the capability to filter issues and merge requests by Release name. This will help find those items associated with a specific Release.

Filter issues and merge requests by Release

Automated Release Evidence collection to support audits

Automated Release Evidence collection to support audits

When development teams release code changes in many organizations, they are required to document the proof that they complied with the organization’s processes and policies in their SDLC. Typically, this can be time consuming and inefficient. In 12.6, GitLab Releases now have a new Evidence collection entry in which you can find a snapshot of the Release’s metadata in JSON format. This snapshot can be leveraged as a chain of custody to support review and compliance processes, such as audits.

Automated Release Evidence collection to support audits

Maintain a consolidated commit history with squash-and-merge in Merge Trains

Maintain a consolidated commit history with squash-and-merge in Merge Trains

Squash-and-Merge allows you to combine all your merge request’s commits into one so you retain a clean history in the default branch while preserving the entire commit history in the merge request. In this release, we added squash support to Merge Trains, which allows running a build on the result of the merged code prior to merging, as a way to keep master green. The combination of these two features will ensure that master is always green while attaining a consolidated commit history.

Maintain a consolidated commit history with squash-and-merge in Merge Trains

View your Security and Compliance config from a centralized interface

View your Security and Compliance config from a centralized interface

We are excited to announce a new ability to view the Secure scanners. You will see a new Configuration option under the Security and Compliance section on the left navigation. This UI will show you which security scans are available, what scans have been configured, and provide clear links to the relevant scanner documentation.

Note: as this is the initial MVC of this new feature, there currently is no advanced configuration, so you cannot disable or enable the scans from this screen.

View your Security and Compliance config from a centralized interface

Collaborate more effectively on GitLab activity directly within Circuit

Collaborate more effectively on GitLab activity directly within Circuit

Circuit by Unify is a collaboration and communication system used by many organizations. Similar to other notification integrations within GitLab, you can now configure webhooks to send selected notifications to a Circuit conversation. Notifications link back to your GitLab project, eliminating the need to context switch between an email client in order to keep up to date with GitLab activity.

Thanks to Fabio Huser for your contribution

Collaborate more effectively on GitLab activity directly within Circuit

12.6 Other improvements in GitLab 12.6

Entropy requirements for new user passwords

Entropy requirements for new user passwords

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).

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.

Require rotation of personal access tokens

Require rotation of personal access tokens

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).

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.

Protect your project data with soft deletion for projects

Protect your project data with soft deletion for projects

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.

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.

Disable group mentions

Disable group mentions

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.

Thanks @fh1ch and Siemens!

Disable group mentions

Deduplicate forks of internal projects

Deduplicate forks of internal projects

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.

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.

Thanks Brian Kabiro for your contribution!

Real-time merge request widget updates

Real-time merge request widget updates

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.

Remove need for client-based authorization with Visual Review Tools

Remove need for client-based authorization with Visual Review Tools

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

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

Remove need for client-based authorization with Visual Review Tools

Inherited variables are now shown in project view

Inherited variables are now shown in project view

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.

API endpoint to list the packages of a group

API endpoint to list the packages of a group

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.

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.

Edit a release via the Releases page

Edit a release via the Releases page

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.

Control rollout of Feature Flags based on UserID

Control rollout of Feature Flags based on UserID

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.

Control rollout of Feature Flags based on UserID

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.

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

Delete related resources when removing Kubernetes clusters

Automatically use customized deploy values file in Auto DevOps

Automatically use customized deploy values file in Auto DevOps

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.

Cloud Run for Anthos support in GKE Kubernetes clusters

Cloud Run for Anthos support in GKE Kubernetes clusters

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.

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.

Cloud Run for Anthos support in GKE Kubernetes clusters

Knative 0.9 support

Knative 0.9 support

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.

Show recent searches when filtering errors

Show recent searches when filtering errors

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.

Show recent searches when filtering errors

Sort error list by first seen, last seen and frequency

Sort error list by first seen, last seen and frequency

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.

Sort error list by first seen, last seen and frequency

Support for PHP added in License Compliance

Support for PHP added in License Compliance

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).

Dependency Scanning for Java Gradle projects

Dependency Scanning for Java Gradle projects

For users with Java Gradle projects, you can now leverage our Dependency Scanning features.

SAST for Kubernetes manifests

SAST for Kubernetes manifests

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

SAST compatible with private dependencies

SAST compatible with private dependencies

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.

Webhook logs now available for CI integrations

Webhook logs now available for CI integrations

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.

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.

Webhook logs now available for CI integrations

Reduce GitLab memory usage with Puma (Experimental)

Reduce GitLab memory usage with Puma (Experimental)

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%.

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.

Omnibus improvements

Omnibus improvements

Filter members list for users with direct membership

Filter members list for users with direct membership

There are two ways to gain access to a private project or group: a) being directly added to that specific project or group or b) inheriting a role from a parent group. In GitLab 12.6, we’re making it easier to understand the source of a user’s membership by allowing filtering of the Members table specifically for direct members or inherited members.

This is particularly useful for groups with external users or instances using groups for notifying teams of people.

Filter members list for users with direct membership

Simplify user management with Personal Access Token and SSH key inventory

Simplify user management with Personal Access Token and SSH key inventory

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.

Simplify user management with Personal Access Token and SSH key inventory

ConvDev Index is now DevOps Score

ConvDev Index is now DevOps Score

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.

Preview OpenAPI specifications

Preview OpenAPI specifications

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!

Preview OpenAPI specifications

More easily navigate between tabs within Merge Requests

More easily navigate between tabs within Merge Requests

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.

More easily navigate between tabs within Merge Requests

Remove fork relationship when project visibility is restricted

Remove fork relationship when project visibility is restricted

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.

GitLab Runner 12.6

GitLab Runner 12.6

We’re also releasing GitLab Runner 12.6 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.

CI configuration outside of the repository

CI configuration outside of the repository

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.

The GitLab NPM registry now supports installing dependencies

The GitLab NPM registry now supports installing dependencies

In GitLab 12.6, we are very excited to announce that the NPM Registry now supports installing package dependencies. Until recently, running npm install would not work if the version was not included in the command. In addition, the command would not support installing the packages’ dependencies. This was due to us not supporting the required NPM metadata, such as dependencies or tags.

Moving forward, users can expect npm install to work as expected. Next we will work on adding dependencies and tags to the Package Registry UI.

Official GitLab container with AWS client installed

Official GitLab container with AWS client installed

Interacting with a major cloud provider such as AWS, Azure, or GCP is a core component of many delivery pipelines. But before you can automate your cloud interactions, you need to have an environment set up with the appropriate tools. Previously this was something you had to manage on our own, but starting in 12.6, GitLab will provide an official AWS Docker image that will allow you to run aws commands from your CI/CD pipelines. You can access a variety of AWS services using a Docker image that is maintained and kept up-to-date by GitLab.

Delivering an official image is also the first step in supporting AWS deploys to EC2. It’s part of our broader plan to include native support for deploying to multiple cloud providers. We hope to see community contributions for additional cloud providers using this model of pre-built images with included scripts hosted in the official GitLab Cloud Deploy container registry.

Warning for skipping Merge Trains

Warning for skipping Merge Trains

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.

Warning for skipping Merge Trains

Customize Kubernetes namespace per environment

Customize Kubernetes namespace per environment

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).

Allow clearing of cluster cache to avoid getting out of sync

Allow clearing of cluster cache to avoid getting out of sync

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.

Allow clearing of cluster cache to avoid getting out of sync

Install Kubernetes applications using CI template

Install Kubernetes applications using CI template

Installing Kubernetes applications using GitLab CI provides a great way to customize Helm charts prior to installation. In order to make it easier to get started, we have added a CI template with all the currently supported applications. In addition to this template, we have created an example cluster-management project containing all the necessary items required to get started. Simply import and mirror this project to get all the latest supported apps.

Install Kubernetes applications using CI template

Improved integration between Error Tracking and Issue management

Improved integration between Error Tracking and Issue management

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.

Add Sentry as a GitLab Managed App

Add Sentry as a GitLab Managed App

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.

Access Pod Logs Directly from the Operations Tab

Access Pod Logs Directly from the Operations Tab

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.

Access Pod Logs Directly from the Operations Tab

Dependency Scanning improvement for Python projects

Dependency Scanning improvement for Python projects

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.

SAST Support for React framework (JavaScript)

SAST Support for React framework (JavaScript)

If you have projects written using the React framework for JavaScript, you can now use our SAST scanners to find any security issues.

Dependency scanning for Scala projects using the sbt package manager

Dependency scanning for Scala projects using the sbt package manager

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.

Group Webhooks are now editable

Group Webhooks are now editable

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.

When a user has GitLab integrated with Jira, comments are posted in Jira when activity happens in GitLab. This addition allows a user to disable those comments from the configuration page on a per-integration basis.

This is valuable for many users who don’t want to see the comments, but still want to automatically link their Jira issues to their GitLab projects. Additionally, some users have noted use cases where there are Jira users who should not have visibility of activity on the repository for confidentiality reasons. Having more fine-grained control over what content is posted to these comments is valuable for both of these cases.

Deprecations Deprecations

Kubernetes 1.11 no longer supported

Kubernetes 1.11 no longer supported

When deploying GitLab in Kubernetes, the minimum supported version of Kubernetes is now 1.12. Kubernetes 1.11 is no longer maintained upstream, and has recently been dropped by popular container management services such as GKE and EKS. GitLab uses Kubernetes 1.13 by default.

Planned removal date: Dec 22, 2019

Deprecated variables and argument for manual configurations of .gitlab-ci.yml when using Secure features

Deprecated variables and argument for manual configurations of .gitlab-ci.yml when using Secure features

As previously announced in Release Post 12.0, if you have manually configured .gitlab-ci.yml:

  • The command line argument --auth-first-page was removed in issue 7182 and is no longer supported and you need to remove it.
  • The DEP_SCAN_DISABLE_REMOTE_CHECKS flag variable for Dependency Scanning was removed in issue 9953 and is no longer supported and you need to remove it.
  • The sast_container value in the GITLAB_FEATURES pre-defined environment variable was removed in issue 8217 and is no longer supported and you need to change it to container_scanning instead.
  • You also need to verify that you are using the new report syntax, since all Security scanning features are dependent on the reports being available in the expected location. If you do not update to the new report syntax, they will stop working.

If you use the vendored templates instead of manually defining the jobs, you don’t need to do anything.

Planned removal date: Dec. 22, 2019

All find-sec-bugs analyzers have been replaced by spotbugs

All find-sec-bugs analyzers have been replaced by spotbugs

We’ve deprecated our four find-sec-bugs analyzers: find-sec-bugs, find-sec-bugs-groovy, find-sec-bugs-sbt, find-sec-bugs-gradle. You should be using our spotbugs analyzer in place of these.

Planned removal date: Dec. 22, 2019

Elasticsearch 5.6 no longer supported

Elasticsearch 5.6 no longer supported

As we continue to improve and enhance our integration with Elasticsearch, support for Elasticsearch 5.6.x will end with the release of GitLab 12.7. Elasticsearch 5.6 reached its end of life with the release of Elasticsearch 7.x. Updated version requirements for GitLab 12.7 will include support for only Elasticsearch 6.x.

At this time there is no timeline for support of Elasticsearch 7.x with GitLab; you can follow this issue for updates. GitLab recommends self-managed customers upgrade to ElasticSearch 6.x.

Planned removal date: January 22, 2020

Backported os.Expand

Backported os.Expand

In GitLab Runner 13.0 we will remove the backported os.Expand() from Go v1.10.8. This backport was needed to include a change in behavior introduced in Go v1.11. Additional details can be found in issue #4915.

Planned removal date: May 22, 2020

Manual parsing of DockerService

Manual parsing of DockerService

In GitLab Runner 13.0 we will revert to using the default TOML parser. Additional details can be found in issue #4922.

Planned removal date: May 22, 2020

Windows Batch cmd for the shell executor

Windows Batch cmd for the shell executor

In GitLab 11.11, we deprecated the use of Windows Batch executor for the GitLab Runner. Support for Windows Batch will be removed in GitLab 13.0. Additional details can be found in issue #6099

Planned removal date: May 22, 2020

Deprecate Ruby string interpolation on Prometheus queries

Deprecate Ruby string interpolation on Prometheus queries

We plan to remove the Ruby string interpolation (curly braces with a leading percent) in the next major version (GitLab 13.0) and replace it with liquid template support. If you are using the following format 'string_%{variable}_string' on your Prometheus queries to pass parameters, you’ll need to replace it with 'string_{{variable}}_string'.

Planned removal date: May 22, 2020

Gitlab 13.0 will drop support for InfluxDB self monitoring metrics

Gitlab 13.0 will drop support for InfluxDB self monitoring metrics

We plan to remove the GitLab self monitoring metrics collected by InfluxDB in the next major version (GitLab 13.0). Prometheus is our official self monitoring tool for GitLab. It is installed by default on every GitLab instance and is collecting the same metrics as InfluxDB.

Planned removal date: May 22, 2020

Planned removal of PostgreSQL 9.6 and 10.x in GitLab 13.0

Planned removal of PostgreSQL 9.6 and 10.x in GitLab 13.0

To take advantage of improved performance and functionality in PostgreSQL 11 such as partitioning, we plan to require PostgreSQL versions 11 and 12 in GitLab 13.x. To accomplish this, we will be introducing support for PostgreSQL 11 in an upcoming release of GitLab 12.x while maintaining support for 9.6 and 10.x. With the arrival of GitLab 13.0, PostgreSQL 11 will be required.

By minimally requiring PostgreSQL 11, we are able to leverage the new features introduced, without the overhead of maintaining multiple code paths. Going forward, we will be maintaining a yearly cadence of PostgreSQL upgrades, with support for the second and third most recent versions as soon as we are able to add them. We welcome your feedback on the proposed removals. Please comment in the Move to PG 11 and 12 epic.

Planned removal date: May 22, 2020

Move Geo settings to Admin Area > Geo > Settings

Move Geo settings to Admin Area > Geo > Settings

Geo settings have moved to Admin Area > Geo > Settings. The old location (Admin Area > Settings > Geo) will remain available with automatic redirection until GitLab 13.0.

Planned removal date: May 22, 2020

Removals and breaking changes Removals and breaking changes

The complete list of all removed features can be viewed in the GitLab documentation. To be notified of upcoming breaking changes, subscribe to our Breaking Changes RSS feed.

Important notes on upgrading to GitLab Important notes on upgrading to GitLab 12.6

As part of our architecture updates for GitLab pages, Pages will be using an API instead of using disk-database access. This has already been done on GitLab.com.

To help with the larger migrations, we have introduced background migrations (Sidekiq jobs that will run asynchronously) for this release. For GitLab.com, these migrations took around 36 hours to complete, and no side effects were expected nor introduced.

To find the approximate time it will take to complete these migrations on your instance, run the following command from a Rails console: (Project.count.to_f / 300_000).ceil. To check the status of the background migrations, run: Sidekiq::Queue.new ('background_migration').size.

For more information see the issue for Pages virtual host configuration API.


Changelog Changelog

Please check out the changelog to see all the named changes:

Installing Installing

If you are setting up a new GitLab installation please see the download GitLab page.

Updating Updating

Check out our update page.

Questions? Questions?

We'd love to hear your thoughts! Visit the GitLab Forum and let us know if you have questions about the release.

GitLab Subscription Plans GitLab Subscription Plans

  • Free

    Free-forever features for individual users

  • Premium

    Enhance team productivity and coordination

  • Ultimate

    Organization wide security, compliance, and planning

Try all GitLab features - free for 30 days

Cover image licensed under Unsplash

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

Take GitLab for a spin

See what your team could do with The DevSecOps Platform.

Get free trial

Have a question? We're here to help.

Talk to an expert
Edit this page View source