Feb 22, 2019 - Joshua Lambert    
11.8

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

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

JavaScript coverage in SAST

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 for subgroups and templates

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.

Error Tracking with Sentry

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.

And many more great features!

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.

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

Join us for an upcoming event

GitLab MVP badge

This month's Most Valuable Person (MVP) is Aaron Walker

Contributor walkafwalka added two new Auto DevOps features this release, support for custom domains and redeployment when only secrets have changed. Thank you for the great improvements!

Key features released in GitLab 11.8

SAST support for JavaScript

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

Error tracking with Sentry

Keeping an eye on errors generated by your application helps maintain a good user experience by detecting problems before users report them and speeding up resolution when they occur.

GitLab 11.8 makes it more convenient and efficient to monitor errors by integrating with popular open source error tracker Sentry, and displaying the most recent errors right within your GitLab project.

Sentry has recently improved their GitLab integration, enabling detection of suspicious commits, release and commit tracking, and more. With the combination of both integrations you’ll have a simple path to Sentry from GitLab, as well as a clean way to get to GitLab from Sentry, so that you can always address errors contextually, staying within your existing workflow.

Error tracking with Sentry

Create Pages sites in one click using bundled templates

We are now bundling our most popular Pages templates directly in GitLab, opening up the possibility of creating your sites directly from the new project creation screen instead of having to fork a sample repository as before.

Check out our blog post about using GitLab Pages templates for more.

Create Pages sites in one click using bundled templates

Pages support for subgroups

Pages have been updated to work with subgroups in GitLab, giving you the ability to create Pages sites there as well. Sites set up in this way will have a URL in the format of toplevel-group.gitlab.io/subgroup/project. This will give your projects, even when part of subgroups, access to the ability to create documentation or other sites needed as part of releasing your software.

Pages support for subgroups

Merge Request Approval Rules

Code review is an essential practice of every successful project, but who should review the changes is not always clear. It is frequently desirable to have a variety of reviewers from different teams like Engineering, UX, and Product.

Approval Rules, new in GitLab 11.8, allow you to better communicate who should participate in code reviews by specifying the eligible approvers and the minimum number of approvals for each. Approval rules are shown in the merge request widget so the next reviewer can quickly be assigned.

In GitLab 11.3 we introduced Code Owners to indicate which team members are responsible for which code in your project. Code owners are integrated into approval rules so that finding the right people to review your change is always easy.

Approval Rules are disabled by default in 11.8 and must be enabled by an instance administrator by executing Feature.enable(:approval_rules) in the rails console.

Approval Rules have temporarily been disabled on GitLab.com. We expect to be re-enabled after deploying GitLab 11.8.1. Follow this issue for updates.

Merge Request Approval Rules

Improved cross-project pipeline triggers

Starting with GitLab 9.3, you’ve been able to create multi-project pipelines by triggering a downstream pipeline via a GitLab API call in your job. In 11.8, we’ve added first-class support for triggering these downstream pipelines with the trigger: keyword, which can be added to a bridge job to automatically trigger a downstream pipeline when the current pipeline succeeds.

Improved cross-project pipeline triggers

Improved squash commit messages

Creating Git history that is readable and useful to people in the future can be at odds with pushing small commits to fix a unit test or resolve feedback. Commit squashing combines all these commits into a single tidy change, but at the same time wipes out your thoughtful commit messages.

GitLab now defaults the squash commit message to the first multi-line commit message in the feature branch, and allows you to override the commit message so that you can update it to reflect any important changes.

Improved squash commit messages

Auto DevOps support for environment-specific custom domain

Auto DevOps allows you to quickly get started by adding a “base domain” for your projects. When your application is ready for production deployment, you may then want to use a custom, fully qualified domain name.

You can now use the environment variable ADDITIONAL_HOSTS to specify one or more custom domains for your application. Furthermore, you can scope it to a specific environment by prepending the environment name to the variable, ie. <ENVIRONMENT>_ADDITIONAL_HOSTS.

Thank you Aaron Walker for the contribution!

Auto DevOps support for environment-specific custom domain

Show function scale for Knative functions

Deploying functions using GitLab Serverless comes with all the benefits of Knative, such as scaling your serverless deployments up and down to zero.

You can now see the scale of your serverless deployments for each application or function deployed to your Knative instance. Scale is illustrated by the number of Kubernetes pods currently in use.

Show function scale for Knative functions

Other improvements in GitLab 11.8

Specify the first day of the week

Before, calendars in GitLab assumed that weeks began on Sunday. Users can now elect in their profile preferences to have their first day of the week begin on Monday, which is reflected throughout the application in date pickers and contribution graphs.

Thank you Fabian Schneider for the contribution!

Specify the first day of the week

Authenticate credentials from a smart card with LDAP

Organizations using smart cards as authentication tokens frequently use LDAP for centralized identity management. In 11.8, we’re iterating on the smart card authentication added in 11.6 by allowing credentials on a smart card to be authorized against a configured LDAP server.

GitLab’s approach follows RFC4523 schema standards using the certificateExactMatch rule.

Upgrade Kubernetes Runner application via Kubernetes integration

Keeping your Kubernetes-deployed apps running on the latest version ensures you have the newest features as well as up-to-date security.

GitLab 11.8 allows you to upgrade the GitLab runner running in Kubernetes with a single click. Future releases will include similar functionality for the rest of the applications.

Upgrade Kubernetes Runner application via Kubernetes integration

Record of a user's last activity in GitLab now includes browsing

GitLab includes a user attribute, last_activity_on, to help admins understand when a user’s last activity was taken. This is very helpful for finding active and inactive users.

To ensure we’re capturing read-only activity, we’ve expanded last_activity_on to update on visits to pages related to dashboards, projects, issues, and merge requests.

Search repository tags in a project via the API

You can now search for repository tags in a project via the Tags API. This makes finding a specific tag in a project more straightforward; if you’re looking for related projects that match a specific version tag, you’re now able to find matching projects with ease.

Thank you Robert Schilling for the contribution!

Improved group overview with reduced white space

In 11.8, we’ve made the group overview more information dense with a redesign. We’ve reduced the amount of whitespace on this page and aligned the user experience with the project overview redesign.

This is the first iteration of a larger set of improvements to the group overview page, and we’re excited to continue iterating on this page.

Improved group overview with reduced white space

We’ve restyled the related merge requests section in an issue, to bring visual consistency to related issues and improve aesthetic appearance.

We’re even adding more metadata to each row in the design in a future release, to help users see relevant merge request information even more quickly and in context.

Redesigned related merge requests, consistent with related issues

Manage group labels via the API

You can now manage group labels via the API, similar to project labels, helping further support customized planning and execution workflows on your teams.

Thank you Robert Schilling for the contribution!

Predefined Pages variables in CI

CI_PAGES and CI_PAGES_URL have been added as CI variables for Pages pipelines, giving you visibility into the Pages domain name and URL. This allows for more flexibility when working with Pages sites hosted in multiple locations.

Gitaly support for TLS

Gitaly now supports TLS, which means all communication between GitLab and Gitaly will be encrypted when TLS is enabled. Previously, communication between GitLab and Gitaly was not encrypted, but relied on the security of the network.

Jump to file in merge request diff

Reviewing large merge requests can be difficult, particularly jumping from one file to another. The new fuzzy file finder makes moving from one file to another painless, so that you can quickly navigate the diff using your keyboard.

Jump to file in merge request diff

Receive alerts from manually configured Prometheus instances

In GitLab 11.3 support for setting alerts was introduced, however it was limited to Prometheus instances which were deployed through the GitLab Kubernetes integration.

With GitLab 11.8, manually configured Prometheus servers can now also notify GitLab of alerts, by simply adding GitLab as a webhook receiver in alertmanager. After receiving an alert, GitLab will email Maintainers and Owners of the project.

Receive alerts from manually configured Prometheus instances

Confidential issues for security vulnerabilities

Users can create a new issue to address and remediate security vulnerabilities from the security reports in a merge request, in the pipeline view, and in the Security Dashboard. This information contains sensitive data that may disclose confidential details that should not be disclosed before a fix is available and released.

Starting with GitLab 11.8, issues created from a vulnerability are marked as confidential by default, and users can turn the flag off when the information can be disclosed.

Display cluster environment in serverless function list view

The Serverless page has been improved and will now group functions deployed to Knative based on the cluster environment they are deployed to.

In addition, function description is now displayed along with shortcut button to copy the function endpoint and another open the endpoint in a new tab.

GitLab Runner 11.8

We’re also releasing GitLab Runner 11.8 today! GitLab Runner is the open source project that is used to run your CI/CD jobs and send the results back to GitLab.

Most interesting changes:

List of all changes can be found in GitLab Runner’s CHANGELOG.

Performance improvements

We continue to improve the performance of GitLab with every release, for GitLab instances of every size.

In GitLab 11.8, we have significantly improved the performance of checking task lists in issues, merge requests, and epics by not re-rendering the entire description after a task is checked or unchecked

Scroll roadmap forward into the future and backward into the past

When you first load the roadmap view, GitLab preselects a time period for you, with options to select weekly, monthly, or quarterly intervals. But the view was fixed, and epics outside of what was displayed were hidden.

With this release, you can now scroll forward into the future and backward into the past. Epics that fall in these expanded times will automatically appear in the view, without requiring you to refresh the page in any way, allowing you a seamless experience to see even more epics in as long of a timeline you need.

Scroll roadmap forward into the future and backward into the past

Feature Flags for Environments

It is now possible to individually turn feature flags on or off on a per-environment basis. The behavior of your feature flags is controlled by creating a set of rules based on matching the environment name. There is always a default wildcard rule (*), but you are also able to add more rules by adding more environment specs (for example, review/*).

In 11.8.0 this feature will require enabling the feature flag, by executing Feature.enable(:feature_flags_environment_scope) in the rails console.

Feature Flags for Environments

User activity and creation dates shown in admin panel

Understanding the activity level of users in GitLab should be an easy task for instance administrators. To help, we’ve added user creation date and the date of a user’s last activity to the Users area of the admin panel at /admin/users.

You can read more about the types of actions GitLab considers activity here.

User activity and creation dates shown in admin panel

Project tags are now project topics

Project tags are a useful way to organize related projects, but the term “tag” collided with Git tags. To resolve this, we’ve renamed project tags to project topics and improved their presentation on the project overview page.

We’re excited to make topics more useful for project discoverability, and are adding topic filtering to the project dashboard in 11.9.

Improved project lists with more information density

We’ve responded to user feedback on our first project list redesign by improving the information density on this page with an additional column and less whitespace.

Improved project lists with more information density

Child Epics in Epics API

In our previous release, we launched child epics, the ability to attach epics to epics. With this release, you can now manage these epic relationships via the API as well. So you can now manage customized workflows in your teams, especially through automation.

Move Auto DevOps domain from CI/CD settings to cluster settings

Specifying a base domain for Auto DevOps allows you to take advantage of powerful features such as Auto-Review Apps and Auto-Deploy. We’ve now made it even easier to specify the base domain by moving it directly to cluster settings. This will make it simple to define the base domain when the cluster is created, and also to define different domains for different clusters.

Move Auto DevOps domain from CI/CD settings to cluster settings

.html extensions are now automatically resolved for Pages sites

A file in your Pages site called /sub-page.html can now also be accessed as /sub-page, giving you more options over how your site appears to your users.

Add tolerations to Kubernetes executor

Kubernetes provides an exciting opportunity to disconnect the underlining hardware from where our workloads run. However, some tasks require specialized hardware – including jobs that may require more resources than others.

Kubernetes supports this by introducing taint and toleration to nodes in order to include these considerations when scheduling pods. We’ve added native support for taints and tolerations in the Kubernetes executor in GitLab Runner to support these types of workflows.

Gitaly support for Elasticsearch

Previously, you had to use NFS to talk to Git in the filesystem if you were using Elasticsearch. With this release, you can use Gitaly instead of NFS, improving Git access performance.

Approval counts in the merge request list

Merge requests that are approved and ready to merge can now be spotted easily from the merge request list. The number of approvals required and number of approvals received is now shown in the merge request list.

Thank you Andy Steele for the contribution!

Approval counts in the merge request list

Clean up unused tags from the Container Registry using the API

Many organizations build containers on every commit, to facilitate validation of code changes, as well as final deployment. This can lead to a large number of container tags that are used for a short period of time, and are no longer necessary.

GitLab 11.8 now allows end users to clean up their container registries using our API, by deleting tags singly or in bulk using a regex.

Force re-deploy when Auto DevOps application secrets are updated

When you configure an app secret for Auto DevOps using the K8S_SECRET_ variable syntax, a matching Kubernetes secret will be created for your application.

When these app secrets are updated, Auto DevOps will redeploy your application with the updated secrets.

Thank you Aaron Walker for the contribution!

Ensure Cert-Manager works with Auto DevOps URLs

Cert-Manager provides an easy way to add HTTPS support for your Auto DevOps applications. This release adds support for URLs longer than the default 64 characters supported by Let’s Encrypt, providing more flexibility for your applications.

Omnibus improvements

  • GitLab’s docker-distribution-pruner is now bundled with Omnibus, allowing administrators a method to clean up registry storage.
  • GitLab 11.8 includes Mattermost 5.7.1, an open source Slack-alternative whose newest release includes several user experience improvements. This version also includes security updates and upgrading is recommended.
  • node_exporter no longer runs by default in the Omnibus docker image, as it requires access to the host.
  • Additional alerts have been added, notifying administrators about: high unicorn utilization, sidekiq job queues, postgres deadlocks, high error rates, and more.
  • nginx has been updated to 1.12.2, registry to 2.7.1, and gitlab-elasticsearch-indexer to 1.0.0.
  • prometheus has been updated to 2.6.1, node_exporter to 0.17.0, and redis_exporter to 0.26.0.

GitLab chart improvements

Deprecations

Ruby 2.5 required

Beginning with GitLab 11.6, Ruby 2.5 is required to run GitLab. Omnibus GitLab and the GitLab Chart already ship with Ruby 2.5.3, but users of source installations that run Ruby 2.4 will have to upgrade.

Removal date: Dec. 22, 2018

Raspbian Jessie support

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

Developers can delete Git tags in GitLab 11.9

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

Removal of the System Info section in the admin panel

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

Changelog

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

Installing

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

Updating

Check out our update page.

GitLab Subscription Plans

GitLab is available in self-managed and cloud SaaS options.

Self-managed: Deploy on-premises or on your favorite cloud platform.

  • Core: For small teams, personal projects, or GitLab trials with unlimited time.
  • Starter: For co-located teams with few projects who need professional support.
  • Premium: For distributed teams who need advanced features, high availability, and 24/7 support.
  • Ultimate: For enterprises that want to align strategy and execution with enhanced security and compliance.

Cloud SaaS - GitLab.com: hosted, managed, and administered by GitLab with free and paid subscriptions for individuals and teams.

  • Free: Unlimited private repositories and unlimited collaborators on a project. Private projects get access to Free features, public projects get access to Gold features.
  • Bronze: For teams that need access to more advanced workflow features.
  • Silver: For teams that need more robust DevOps capabilities, compliance and faster support.
  • Gold: Great with many CI/CD jobs. Every public project get the features of Gold for free irrespective of their plan.

Cover image licensed under Unsplash

Try all GitLab features - free for 30 days

GitLab is more than just source code management or CI/CD. It is a full software development lifecycle & DevOps tool in a single application.

Try GitLab for Free

Try GitLab risk-free for 30 days.

No credit card required. Have questions? Contact us.

Gitlab x icon svg