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.

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.

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.

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

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.

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.

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.

Join us for an upcoming event

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!

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 .

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.

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.

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

Thank you Aaron Walker for the contribution!

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 .

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.

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.

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.

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.

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.

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.

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

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.

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.

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

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.

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.

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.

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.

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.

Thank you Aaron Walker for the contribution!

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

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.

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.

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.

Thank you Andy Steele for the contribution!

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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

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 .

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

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

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.

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.

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

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

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

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.

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.

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

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.

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.

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.

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 .

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.

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.

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.

Thank you Robert Schilling for the contribution!

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

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.

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

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.

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 .

Thank you Robert Schilling for the contribution!

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.

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.

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.

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.

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

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.

Thank you Fabian Schneider for the contribution!

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.

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.

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

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

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

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

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

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

Deprecation date: Apr. 22, 2019

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.

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

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

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

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

Deprecation date: Jun. 22, 2019