GitLab 11.8 released with SAST for JavaScript, Pages for subgroups, and Error Tracking


GitLab Static Application Security Testing (SAST) scans source code and helps to detect potential security vulnerabilities early in the pipeline. In 11.8, we've added SAST support for JavaScript, building on top of our existing node.js support. Now any JavaScript file can be scanned, like static scripts and HTML. A vital practice in DevSecOps is to scan code changes with each commit, and with this change, we're covering one of the most popular web languages, helping you to find JavaScript risks as early as possible.

GitLab Pages got a whole lot better this release, with two key improvements. First, we have introduced GitLab Pages support for projects in subgroups, enabling these projects to easily publish content to the web. GitLab 11.8 also bundles our most popular templates for Pages, so users can get started with just a single click.

Application errors provide important insight into the health of your application, and can help detect problems without waiting for users to report them. GitLab 11.8 can now display the most recent errors directly within the project, making them easier and quicker to find and take action on.

There are so many great features in this release, that we wanted to highlight a few more:

  • Merge Request Approval Rules: Easily define rules for who needs to approve a change, whether it's a specific user, group, or role. Available on GitLab.com soon, and can be enabled in your own GitLab instance by an administrator.

  • Feature Flags for Environments: Previously, feature flags were either on or off across all of your environments. No more! Feature flags can now be selectively enabled on a per-environment basis. Available on GitLab.com today, and can be enabled in your own GitLab instance by an administrator. We plan to make it on by default in 11.8.1.

  • Improved Squash Commit Messages: For those who enjoy crafting great commit messages, it can be sad to see them lost in a squashed commit to keep things tidy. On 11.8 squashed commits now automatically utilize the first multi-line commit message, and can also be overridden to make them even better.

Key features released in GitLab 11.8

Static Application Security Testing (SAST) allows you to spot vulnerabilities in your source code every time you commit a new change to the repository. With this information available in the merge request, you can shift security left and address problems even before they are merged into the stable branch.

With 11.8, we add JavaScript to the list of languages supported by SAST. You don’t need to change anything in your pipelines. JavaScript projects are automatically detected and analyzed for security vulnerabilities. It is also part of Auto DevOps.

SAST support for JavaScript

GitLab 11.8 is the last release with support for Raspbian Jessie.

Jessie has transitioned to LTS, and the latest Raspbian Jessie image is over a year old. We recommend that users upgrade to Raspbian Stretch.

Removal date: Feb. 22, 2019

Google OAuth2 SSO only supported in GitLab 11.7+

On Mar. 7, 2019, Google is shutting down all Google+ APIs. You can read more about the announcement from Google here.

Since GitLab versions prior to 11.7 rely on these APIs for Google OAuth2, Google single sign-on will no longer function on these versions. GitLab 11.7 and beyond will support Google SSO.

If your instance relies on Google OAuth2 for authentication, we recommend upgrading to 11.7.

Removal date: Mar. 7, 2019

Removing or modifying release notes for Git tags on non-protected branches has been historically restricted to Maintainers and Owners.

Since Developers can add tags as well as modify and remove non-protected branches, Developers should be able to remove Git tags as well. In GitLab 11.9, we’re making this change to our permissions model to improve workflow and help developers make better and more effective use of tags.

If you’d like to continue to restrict this permission to Maintainers and Owners, you can make use of protected tags.

Removal date: Mar. 22, 2019

Hipchat integration

Hipchat will be discontinued. So we are removing the existing GitLab Hipchat integration feature as part of the 11.9 release.

Removal date: Mar. 22, 2019

CentOS 6 support for GitLab Runner using the Docker executor

Runner support for CentOS 6 when using the Docker executor will be removed in GitLab 11.9 because we are updating to a more current Docker library which no longer supports CentOS 6. Please see this issue for additional details.

Removal date: Mar. 22, 2019

GitLab presents information about your GitLab instance at admin/system_info, but this information can be inaccurate.

We’re removing this section of the admin panel in 11.10, and recommend using other monitoring capabilities.

Removal date: Apr. 22, 2019

GitLab.com Pages domains that are not validated will be removed after one week

In order to improve performance of GitLab.com, domains that are not able to be validated will be deleted after one week (the validation will be tried for four days before the one-week countdown starts.) If you are relying on holding the domain with GitLab without having done validation, you will now need to complete that step in order to ensure that the domain remains registered with you. Please see the instructions on how to validate your domain to ensure you do not run into any issues. If your GitLab.com Pages domain is not serving 404 errors, then it is already validated.

See gitlab-ce#44696 for details on the plan for cleanup.

Removal date: Apr. 22, 2019

Support for Prometheus 1.x in Omnibus GitLab

With GitLab 11.4, the bundled Prometheus 1.0 version is deprecated in Omnibus GitLab. Prometheus 2.0 is now included, however the metrics format is incompatible with 1.0. Existing installations can upgrade to 2.0 and optionally migrate their data using an included tool.

With GitLab 12.0, any installation not yet running Prometheus 2.0 will be automatically upgraded. Metric data from Prometheus 1.0 will not be migrated, and will be lost.

Removal date: Jun. 22, 2019

TLS v1.1 will be disabled by default in 12.0

Beginning with GitLab 12.0, TLS v1.1 will be disabled by default to improve security. This mitigates numerous issues including Heartbleed and makes GitLab compliant out of the box with the PCI DSS 3.1 standard.

To disable TLS v1.1 immediately, set nginx['ssl_protocols'] = "TLSv1.2" in gitlab.rb and run gitlab-ctl reconfigure.

Removal date: Jun. 22, 2019

OpenShift template for installing GitLab

The official gitlab helm chart is the recommended method for operating GitLab on Kubernetes, including deployment on OpenShift.

The OpenShift template for installing GitLab is deprecated, and will no longer be supported in GitLab 12.0.

Removal date: Jun. 22, 2019

GitLab Geo will enforce Hashed Storage in GitLab 12.0

GitLab Geo requires Hashed Storage to mitigate race conditions on secondary nodes. This was noted in gitlab-ce#40970.

In 11.5, we added this requirement to the Geo documentation: gitlab-ee#8053.

With 11.6, sudo gitlab-rake gitlab:geo:check checks that Hashed Storage is enabled and all projects are migrated: gitlab-ee#8289. If you are using Geo, please run this check and migrate as soon as possible.

In 11.8, a permanently dismissable warning will be displayed on the “Admin Area › Geo › Nodes” page if the above checks are not resolved: gitlab-ee!8433

In 12.0, Geo will enforce the Hashed Storage requirement: gitlab-ee#8690.

Removal date: Jun. 22, 2019

Cover image licensed under Unsplash