Nov 22, 2018 - Fabio Busatto  
11.5

GitLab 11.5 released with Group Security and Operations Dashboards, and Access Control for Pages

GitLab 11.5 released with Group Security and Operations Dashboards, Access Control for GitLab Pages, Knative for Kubernetes, and much more!

Group dashboard for security teams

For a long time, developers have used GitLab as a tool to secure their code. But now, GitLab is making security teams first-class citizens so they can use GitLab to effect better application security and ensure compliance. With 11.5, the Group Security Dashboard pulls together all of the information security personnel need into one place, so folks like CISOs, CIOs, and application security leaders get a specific view designed for them. The group dashboard has a redesigned look and new visualizations, bringing together security information across multiple projects and providing a high-level view while also enabling the ability to drill down into specific reports. With 11.5, we're starting with SAST reports, and we'll be adding more to the group dashboard in the future. Our goal is to build a single tool that security teams can use instead of needing to switch back and forth between multiple tools.

New dashboard for operations teams

In the same way that the Group Security Dashboard makes security teams first-class citizens, the Operations Dashboard provides a tailored experience for operations professionals. This instance-wide dashboard provides a single view across projects to get a summary of each project’s operational health, including pipeline and alert status.

Control access to GitLab Pages

GitLab Pages is an easy way to serve static content on the web, making it perfect for use cases such as documentation for your project. But what about private projects where documentation and other static artifacts should only be accessed by project members? In the past, you'd either have to make your assets public to take advantage of Pages, or you would not be able to use the feature at all.

Now, in GitLab 11.5, the same access control permissions that apply to your issues and code can also be applied to static webpages served by GitLab Pages. Unauthenticated users will get a 404 when visiting the link. As of today, access controls for GitLab pages is available for self-managed GitLab, with GitLab.com support coming soon.

This is a unique feature that we're particularly proud of because it comes from our open source community. Access control for Pages has been one of our most requested features and the code has been community contributed as well!

Knative for Kubernetes

“Serverless” is a popular, yet often misunderstood industry term. Some folks equate serverless with "Function as a Service," or FaaS, but this isn't quite accurate. In a nutshell, serverless enables a programming paradigm where you are able to focus on writing business logic without having to understand or even worry about the underlying infrastructure where your software is deployed. As such, both functions and applications can be serverless.

Knative is a Kubernetes-based platform to build, deploy, and manage modern serverless workloads, and GitLab 11.5 comes with the ability to easily deploy and integrate Knative with GitLab. You can now install Knative to your connected Kubernetes cluster with a single click. With GitLab 11.5, you'll be able to use Knative for your serverless applications, with serverless functions coming in 11.6.

Today, Knative is still in alpha, but there are some compelling reasons to deploy applications using Knative as it comes with some powerful functionality out-of-the-box. In particular, Knative manages pod scaling for you so you can automatically scale up, or even scale down to zero without additional configuration. Additionally, Knative comes with eventing built in so using it to deploy microservices makes it easier to manage inter-process communication between your producer and consumer services.

And so much more!

With so many great features in this release, we couldn't pack them all into the intro. Be sure to read up on other exciting new features like the parallel attribute for faster pipelines, redesigned Issue Board cards, and an initial Jaeger integration. We’ve made big improvements in this release to make code review easier and more useful, including the ability to comment on unchanged lines in merge requests, preview merge request reviews before submitting, and assign approvers based on Code Owners along with Review App direct links. Keep reading to see all of the features that are part of this release.

Join us for an upcoming event

GitLab MVP badge

This month's Most Valuable Person (MVP) is Tuomo Ala-Vannesluoma

Tuomo did an amazing job by implementing Access control for Pages, a highly requested feature. Private projects can now restrict access to their content to authorized users. This enables groups of people to host internal web pages that may contain sensitive information, for example.

Thank you, Tuomo! This feature required a significant amount of work across gitlab-ce, gitlab-pages, and omnibus-gitlab GitLab projects.

Key features released in GitLab 11.5

Group Security Dashboard

Security teams need to easily access information about the security status of all their projects, so they know which is the most important task to take next. This is even more important for Directors of Security that need to have a high-level view of possible critical issues affecting the entire development.

With GitLab 11.5, a first iteration of a new Security Dashboard is available at group level. It provides a summary for all the SAST vulnerabilities in all the projects in that group, and a list of actionable entries that can be used to start a remediation process. For example, you can open an issue with a suggested solution, or simply dismiss the entry if you classify it as a false positive. Support for other tests (Dependency Scanning, Container Scanning, DAST) will be added in the future.

Note: The Group Security Dashboard requires the new reports syntax and GitLab Runner 11.5 or higher in order to display results. Auto DevOps will be supported in a future release.

Group Security Dashboard

Operations Dashboard

For organizations who have embraced DevOps, and for teams with more operations-leaning members, it is important to be able to quickly ascertain the health of the projects in your organization.

GitLab 11.5 introduces a new, operations-focused dashboard, providing a summary of the key operational metrics of each project a user is interested in. This includes the time since the last deployment, most recent commit, as well as whether there are any active alerts.

The dashboard can be set as a user’s preferred homepage, or accessed via clicking on the new dashboard icon in the top bar.

Operations Dashboard

Access control for Pages

The 11.5 release introduces a fantastic new community-contributed feature which enables access control for Pages. Now, instead of only supporting use cases where the content associated with the product is public, you can use Pages to build and publish protected content that should only be accessible by project members. Operational documentation, internal secrets, or even just private planning or other information can now be confidently published automatically in an easy-to-access way, while ensuring only the right people are able to see it.

This is currently not enabled on GitLab.com, you can follow issue 5576 for more information.

Access control for Pages

Easily deploy and integrate Knative with GitLab

Building serverless applications enables teams to focus their time on making a great product and eliminates the need of provisioning, managing, and operating servers.

Starting in GitLab 11.5, you can now deploy Knative to your existing Kubernetes cluster with a single click using the GitLab Kubernetes integration. Knative is a Kubernetes-based platform to build, deploy, and manage modern serverless workloads. Tasks that were once difficult, such as source-to-container builds, routing and managing traffic, and scaling-to-zero, now work effortlessly out of the box.

Easily deploy and integrate Knative with GitLab

Assign approvers based on Code Owners

Knowing who to ask to review your merge request isn’t always obvious. Code Owners, which allow files to be assigned to the responsible team members, are now automatically assigned as merge request approvers.

Assigning approvers automatically based on Code Owners will notify the relevant Code Owners of impending changes so that they are able to review and approve the changes.

Support for defining Code Owners was introduced in GitLab 11.3. In upcoming releases, Code Owners will be further integrated into the merge request workflow with required approvals.

Assign approvers based on Code Owners

Parallel attribute for faster pipelines

The speed of pipelines is an important factor for any team, and running tests or other parallelizable tasks tends to take a big chunk of the time for any build. Adding this new keyword gives teams the ability to simply parallelize tests, allowing everyone to accelerate their software delivery process. To use this feature, simply set the parallel attribute to how many copies of the task you’d like to split it into, and GitLab will handle the work of automatically creating the appropriate number of jobs running your task.

Parallel attribute for faster pipelines

Other improvements in GitLab 11.5

Comment on unchanged lines in merge request

An important purpose of code review is to draw attention to aspects of the proposed change that may not have been considered. Often this means pointing out unforseen consequences in areas of the code base that are unchanged.

GitLab now supports commenting on both changed and unchanged lines in merge request diffs, so that you can directly draw the attention of the author to changes that are required that have not yet been made. When reviewing a merge request diff you can expand collapsed, unchanged lines using the ellipsis () button.

In upcoming releases, support for commenting on unchanged lines will be expanded from changed files to unchanged files.

Comment on unchanged lines in merge request

When you’re working on a branch and have only changed a few files, it’s not very helpful for the Review App link to take you to the root of the website. To make this more useful, we’ve added a dropdown selector to the Review App link which can now take you directly to the page(s) that you’ve changed.

Review App direct link

Preview merge request review before submitting it

Code review is an essential practice of successful projects, but providing clear and actionable feedback can be difficult. A particular challenge is avoiding leaving comments that become irrelevant or incomplete as one’s understanding of the changes improves as one reads more of the diff.

With this release you are now able to preview your merge request review before submitting. Merge request reviews, introduced in GitLab 11.4, allow reviewers to draft many items of feedback and submit them all as a single action.

In future iterations, we will improve the feature to send one email notification per merge request review.

Preview merge request review before submitting it

New CI/CD syntax for security, quality, and performance report types

Before GitLab 11.5, reports like SAST or DAST relied on a combination of job and artifacts names to be recognized as such by the system. This was not optimal to scale and to support more advanced features like the Group Security Dashboard, because of the performance implications to access artifacts. With the previous syntax you needed to use specific job names (like sast) but now you can specify custom job names.

In GitLab 11.5 a new implementation has been introduced to leverage the new reports syntax. New job definitions are now available for SAST, DAST, Dependency Scanning, Container Scanning, License Management, Code Quality, and Browser Performance Testing. The old syntax has been deprecated and could be removed in a future release. You are encouraged to upgrade your definitions in order to benefit from improved performances and the Group Security Dashboard, even if the old syntax is still working. The new syntax requires GitLab Runner 11.5 or above.

Empty state for Wiki-only projects

We’ve improved the experience for Wiki-only projects without a default project overview page. The empty state for this project setup now better encourages users to add a page to the relevant Wiki and get these projects off to a great start.

Empty state for Wiki-only projects

Consistent status-check names for GitHub integration

It is now possible to configure status checks on the GitHub side that can be marked as “required” without having to configure this one by one, based on their name. Previously, the check names included the branch name, so it was not possible to do this easily. This feature is enabled via the GitHub integration configuration section.

Consistent status-check names for GitHub integration

Close epic notification

We recently released the ability to close epics, namely having different open and closed states for epics. In this release, we are adding notifications for closing and reopening epics, to help users follow more closely on work they are interested in.

Close epic notification

Autocomplete epic in issue and merge request

You can now more easily search and refer to epics while working in an issue or merge request. Just type & and enter a few numbers or characters in the issue or merge request’s description or a comment. GitLab’s autocomplete will search for epics in the immediate parent group, allowing you to select one easily all without leaving the current page.

Autocomplete epic in issue and merge request

More information about deployments in merge requests

Currently, environment information is hidden when a newer pipeline is running. With this change we are adding information on in-progress deployments to the widget, so you know that an update is on its way.

One of the most exciting results of this functionality in this release is that the link to the current deployment will remain available in cases where a new deployment is running, allowing you to still find the link to the Review App. In cases where lots of deployments were constantly running, this previously made it quite difficult to get the timing right in some cases.

More information about deployments in merge requests

Automatically navigate to last visited board

As teams use more and more issue boards, it can become cumbersome to navigate among many of them in the dropdown navigation. With this release, GitLab will automatically send you to the last visited board, whenever you access the boards navigation from the sidebar menu of a given project or a group. This is saved to the system, so even if you use GitLab between different browsers and devices, the last visited board will be saved.

Note that you can still directly link to a specific board by saving the URL of the board when you are viewing it.

See upcoming planned improvements to managing multiple boards and participate in the comments.

Milestone changed notification

GitLab milestones are useful for teams to plan and track work to be done in a time-boxed period or to associate with a code release. These dates are important for teams to communicate timelines with each other and stakeholders in general. So when milestones change, it is critical that people are updated.

With this release, we’ve added email notifications for changing milestones in issues and merge requests, so that people can stay updated if a piece of work has been delayed, moved earlier, or just de-scoped.

Milestone changed notification

Issue Board cards redesigned

A central place of collaboration in GitLab is Issue Boards, where teams can organize and view planned and ongoing work in one location. With this release, we’ve improved the design of issue cards, showing relevant information in a simple and organized manner. We are showing the issue title, time-tracking information, confidentiality, labels, due date, weight, and assignee, all in the card.

Issue Board cards redesigned

RBAC creates service account restricted to project's namespace

Securing Kubernetes instances is paramount for running production-ready, mission-critical apps. RBAC provides great power and flexibility in securing your cluster.

Starting in GitLab 11.5, our Kubernetes integration will create a dedicated service account and role binding for each project’s namespace which will be used in GitLab CI jobs. This eliminates the need to use the cluster-admin token when interacting with GitLab CI runners.

Update Git submodules via API

Git submodules allow you to include a Git repository within another Git repository. GitLab now supports updating the submodule reference via the API. This is particularly useful for automation, allowing you to keep your project up to date with the latest dependencies using the API.

Discussion activity redesign in issues, merge requests, and epics

In this release, we’ve improved the design of discussion activity in issues, merge requests, and epics. We’ve made it easier to read comments and parse system note activity, so you can focus on the information that’s relevant to you at the given moment.

Discussion activity redesign in issues, merge requests, and epics

'Create new group' page redesign

With this release, we are aligning the ‘New group’ page with the ‘New project’ page, consolidating and repositioning relevant fields for clarity and consistency.

'Create new group' page redesign

Remediation info for Gemnasium

Dependency Scanning relies on the Gemnasium service for the majority of supported languages. This allows GitLab to report known vulnerabilities in packages, but this information was missing a remediation that helps developers to easily fix the problem.

With GitLab 11.5, Gemnasium service provides remediations every time the information is available. This is then reported in the vulnerability details window, and in the related issue. For example, the remediation could report the minimum version a library should be updated to in order to fix the security problem.

Remediation info for Gemnasium

GitLab Helm chart improvements

GitLab Runner 11.5

We’re also releasing GitLab Runner 11.5 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:

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

Omnibus improvements

  • GitLab 11.5 includes Mattermost 5.4, an open source Slack-alternative whose newest release includes user-focused features, new data export tool, plus much more. This version also includes security updates and upgrade is recommended.
  • It is now possible to set the desired group name for each GitLab services to run as.
  • Go-based applications included in GitLab Omnibus now utilize the standard Omnibus Gitlab directory for trusted certificates.
  • The maximum number of concurrent connections to GitLab Pages can now be configured using gitlab_pages['max_connections'].
  • bundler has been updated to 1.16.6, unicode-display_width to 1.4.0, gitlab-monitor to 2.19.1, and gitlab-elasticsearch-indexer to 0.3.0
  • We have improved the readability of the list of open source licenses in use by GitLab.

Group file templates

File templates for LICENSE, .gitignore, Dockerfile, and .gitlab-ci.yml files make it easy to add these common files to projects. Custom file templates can now be shared with all the projects in a group and sub-groups, by configuring a template repository for the group.

Custom templates are useful when the templates provided by GitLab are too generic, for example a custom license that should be used for every project in the company, or a complex Dockerfile that should be used for every microservice.

Support for instance-wide template repositories was introduced in GitLab 11.3.

Group file templates

Issue Analytics

In this release, we have provided a dynamic chart showing the number of issues created in your group, per month, for the past year. There is even a filter that allows you to filter down to a particular scope of issues.

This will help teams dig more deeply into their issue analytics. For example, you can quickly see how many bug issues have been created, if you use a bug label.

See how we plan to expand on charting capabilities and please participate in the discussion.

Issue Analytics

Keep your email address private

It’s important to know who is contributing code to your project and be able to look up a commit author in the GitLab interface, using Git locally, or on a fork hosted elsewhere, but this exposes your email publicly.

GitLab now provides a noreply email address that can be used locally and for web commits to help make it easier to keep your email address private.

Keep your email address private

Open a merge request with a patch via email

GitLab has supported opening a merge request via email for a long time, but before sending the email the branch must already exist on the server. Now you can open a merge request with only an email by attaching one or more patch files (.patch).

Patch files are the standard for sharing and transmitting changes between systems. In future releases of GitLab we will build on this foundation for distributed merge requests, which will allow merge requests between GitLab instances, and other Git hosting tools too.

Open Jaeger from GitLab

Tracing provides deep introspection into the performance and health of a deployed application, tracking each function or microservice which handles a given request. This makes it easy to understand the end-to-end flow of a request, regardless of whether you are using a monolithic or distributed system.

GitLab 11.5 includes an initial integration with Jaeger, the CNCF-hosted tracing project, allowing users to easily open the Jaeger UI from GitLab.

Open Jaeger from GitLab

Omnibus Go apps now use the GitLab cert directory

GitLab includes a number of Go-based applications. Prior to 11.5, these applications utilized the standard OS system location for trusted certificates, instead of the Omnibus GitLab directory.

With this release, Go applications now use the same directory for trusted certificates as the rest of GitLab, by default /opt/gitlab/embedded/ssl/certs/, making certificate management easier and more straightforward.

GitLab installations which depended upon the Go applications using the system directory should move those certificates to the standard Omnibus GitLab location.

JSON logging for audit events

In order to make audit events easier to analyze and ingest outside of GitLab, we’ve added audit_json.log to capture audit events in a structured log file. With this change, shipping and parsing logs becomes much easier – especially for visualization and analysis in other tools.

File list for browsing merge request diff

Moving backwards and forwards between files in the merge request diff is necessary in all but the smallest of changes. In addition to the file tree added in GitLab 11.4, GitLab now includes a searchable file list of changes to make it easy to see which files have changed and jump between them, whether you prefer a tree or a list.

File list for browsing merge request diff

Authenticate with Jira Cloud using email address and API token

Jira Cloud is removing usernames for authentication. So to support this change, we now allow you to use an email address and API token to authenticate with Jira Cloud instead.

Authenticate with Jira Cloud using email address and API token

Filter by open or closed epics in API

We recently released the ability to close epics, namely having different open and closed states for epics. In this release, we are exposing that state in the API itself, so that you can filter on open or closed epics when retrieving a list of them, as well as see the state in a single epic retrieved itself.

Epic keyboard shortcuts

Similar to issues and merge requests, you can perform basic operations in an epic page with keyboard shortcuts, helping those users who want to get more done, more quickly, without leaving the keyboard.

Use r to start a new comment. (It will even quote selected text.) Use e to edit the description. And use l to change labels.

Render 'index' files like 'README's in repositories

When a README.* file is present in a directory of a repository, it’s rendered automatically by GitLab without the need to explicitly open it. With GitLab 11.5, it’s now possible to do the same thing with an index.* file.

This is particularly useful when you also deploy your content online using a static site generator. Previously, if you used README.md it would render to README.html, whereas with index.html you can now have clean URLs since most web servers treat http://example.com/page/index.html and http://example.com/page/ the same.

This is not limited to Markdown files as GitLab supports a number of markup languages.

Render 'index' files like 'README's in repositories

Discussion activity filter in issues and merge requests

We are glad to see teams collaborating actively in issue and merge request comments. For more involved discussions and longer-lived issues and merge requests, the discussion activity can become very long, with a lot of generated system notes.

With this release, we’ve implemented a filter to allow you to focus on just comments or system activity in the discussion area of an issue or merge request. Your selection is saved for all issues or all merge requests in GitLab. So if you prefer one mode, you can just make the selection once, and it will persist forever.

We are planning to bring the same functionality to epics too.

Discussion activity filter in issues and merge requests

Show feedback if Git push validation takes too long

Every time you push changes to a Git repository on GitLab, GitLab performs checks on each commit to enforce permissions, repository size restrictions and validates the presence of LFS objects. In some cases large pushes can fail without feedback when validation takes too long.

GitLab now provides feedback when Git push operations time out because validation is taking too long. This will help debug the source of the problem by providing better feedback to the user.

Quick access to prioritized Group settings

With GitLab 11.5, we are iterating on the settings page of Groups to prioritize the most sought-after configuration options. The top-most section is expanded by default, and we’ve clarified labels and links to provide clear direction on where to find settings and what they do. We’re continuously working on this – Project and Admin settings improvements are coming soon!

Quick access to prioritized Group settings

Help menu in top navigation

With this release, we are updating the top navigation bar by moving two items into a new, dedicated Help menu section. We’ll continue to add additional items there related to instance-level support and feedback in future iterations coming soon!

Help menu in top navigation

Audit event logging for project features and group settings

Audit Events captures important events that take place on your GitLab instance, and we’re now capturing additional changes in 11.5:

Activity dashboard redesign

With this release, we are updating the activity dashboard design to give a better view into who is doing what in your GitLab instance. The new activity feed gives a reader more context on what actions have taken place to keep you always up to date.

Activity dashboard redesign

Deprecations

sast_container value in GITLAB_FEATURES environment variable

The GITLAB_FEATURES environment variable, available to CI/CD jobs, lists all the available features based on the current license/tier.

The sast_container value for Container Scanning is now deprecated, and replaced with container_scanning. The old value could be removed in GitLab 12.0.

Removal date: Mar. 22, 2019.

Old CI/CD syntax for security, quality, and performance report types

Before GitLab 11.5, jobs and artifacts had to be named specifically to automatically extract report data and show it in the merge request widget. While these old job definitions are still working, they have been deprecated and may be removed in the next major release, GitLab 12.0.

You are advised to update your current .gitlab-ci.yml configuration to reflect that change. You can find the new definitions in our documentation for SAST, DAST, Dependency Scanning, Container Scanning, License Management, Code Quality, and Browser Performance Testing.

The new syntax requires GitLab Runner 11.5 or newer to work correctly.

Removal date: Mar. 22, 2019.

Pipelines older than three months are no longer re-runnable

As of this release, older jobs (>3 months) will no longer be allowed to be “played” or “retried,” and rollback will no longer be available. As of now we are not actually deleting this data so we can receive feedback on potential problems with this change. Please join the discussion in #50939 if you have concerns.

Removal date: Nov. 22, 2018.

Elasticsearch 5.5 and earlier not supported in GitLab 11.5

GitLab 11.5 will no longer support Elasticsearch 5.5 and below. It will only support Elasticsearch 5.6 and 6.x. See the blog post for additional details.

Removal date: Nov. 22, 2018.

Support for Prometheus 1.x in Omnibus GitLab

With GitLab 11.4 (Oct. 22, 2018) 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: GitLab 12.0

Upgrade barometer

To upgrade to GitLab 11.5 from the latest 11.4 version, no downtime is required. To upgrade without downtime, please consult the documentation on downtimeless upgrades.

For this release we have migrations, post-deploy migrations, and to help with the larger migrations we have introduced background migrations.

GitLab.com migrations took approximately 9 minutes and post-deploy migrations amounted for a total of around 32 minutes. Background migrations on the other hand are sidekiq jobs that will run synchronously, for this release these migrations took around 2 days to complete, no side effects were expected nor present, these target older kubernetes cluster integrations so newer kubernets cluster integrations are not affected.

GitLab Geo users, please consult the documentation on upgrading Geo.

Go apps in Omnibus now use the standard GitLab certificate directory. Installations which depended upon the Go applications using the system directory, should move those certificates to the standard Omnibus GitLab location.

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

Install GitLab in 2 minutes

With Ubuntu, Debian, CentOS, openSUSE, and Raspbian packages or from source

Install GitLab Now

Try GitLab Ultimate risk-free for 30 days.

No credit card required. Have questions? Contact us.