Mar 22, 2018 - Victor Wu  

GitLab 10.6 released with CI/CD for GitHub and deeper Kubernetes integration

GitLab 10.6 released with CI/CD for GitHub, deeper Kubernetes integration, group issue board in Core and Free, and lots more!

Continuous integration, continuous delivery, and continuous deployment form the backbone of modern DevOps. GitLab features built-in CI/CD that has received a lot of positive attention from developers, enterprises, and analysts alike.

But one thing that was missing was that you couldn't use GitLab CI/CD with GitHub.  Well today, we’ve fixed that.

Introducing GitLab CI/CD for GitHub

While GitLab works best when you use it all end-to-end, we also seek to play well with others. In this spirit, we’ve added CI/CD integration with GitHub, and more generally the ability to integrate CI/CD with other external repos like Bitbucket as well. We see four primary audiences that this functionality is designed for. 

Open source projects

If you have a public, open source project on GitHub you can now take advantage of free CI/CD on As part of our commitment to open source, we offer all public projects our highest tier features (Gold) for free. While other CI/CD vendors limit you to running a handful of concurrent jobs, gives open source projects hundreds of concurrent jobs with 50,000 free CI pipeline minutes per month.

Large Enterprises

When we talk to our largest customers they tell us that they often have many teams using many different tools. They want to standardize on GitLab for CI/CD but code is stored in GitLab, GitHub, and other repos. This feature now allows enterprises to use common CI/CD pipelines across all of their different repos. This is a key audience and why we’ve made CI/CD for GitHub part of our self-managed Premium plan.

Anyone using

While GitLab is designed to use SCM & CI/CD in the same application, we understand the appeal of using GitLab CI/CD with GitHub version control. So, for the next year we are making the GitLab CI/CD for GitHub feature a part of our Free tier. That means anyone using GitHub from personal projects and startups to SMBs can use GitLab CI/CD for free. Starting at 2000 free CI pipeline minutes per month, folks can also add their own Runners or upgrade plans to get more.

Gemnasium customers

We recently acquired Gemnasium. While we are super excited about having such a great team join our ranks, we also want to take care of folks that were using Gemnasium and provide them a migration path. We’ve already shipped Gemnasium features as part of our built-in security scanning. Now, GitLab CI/CD for GitHub allows Gemnasium customers that were using GitHub + Gemnasium to begin using GitLab CI/CD for their security needs without needing to migrate their code.

Kubernetes on GitLab keeps getting better

GitLab continues to invest in integrating with containerization. In 10.4 we release Kubernetes Cluster Integration and GKE Integration to General Availability. With this release, we make it even easier for users to use Kubernetes with GitLab. You can now deploy a GitLab Runner to your connected Kubernetes cluster with a single click. You can also monitor your connected Kubernetes cluster from within GitLab itself. And you can now also see the IP address of an Ingress controller connected to your Kubernetes cluster, again, right inside GitLab!

Join us for an upcoming event

GitLab MVP badge

This month's Most Valuable Person (MVP) is Takuya Noguchi

This release’s MVP is Takuya Noguchi. Takuya implemented a re-designed and extremely useful branches page in GitLab, making it much easier to manage active versus stale branches, especially in large projects with many ongoing branches.

Thank you, Takuya for your contribution! We’ve sent Takuya some GitLab swag as a thank you, including a hoodie, socks, and a handmade tanuki.

Key improvements released in GitLab 10.6

GitLab CI/CD for external repos

In 2011, GitLab started out as a code repo alone. Since then, we’ve built an application for the entire DevOps lifecycle that includes rich capabilities for testing, security, packaging, deployment, and monitoring. With this newest release, you can now use GitLab for CI, or even CD and monitoring, all while your application code is hosted in an external repo.

To use GitLab CI/CD with a GitHub repository create a new GitLab project. On the CI/CD for external repo tab, click GitHub to sign in and select your GitHub repo. Once you add a .gitlab-ci.yml file to your repo (or enable Auto DevOps), GitLab will automatically run pipelines and update the commit status in GitHub.

You can also connect to any Git repo via URL and configure status webhooks manually. For example, if you’re using Bitbucket, read how to manually enable GitLab CI/CD.

To celebrate this release, we’re offering this feature promotionally as part of Free through March 2019.

GitLab CI/CD for external repos

Quick deploy of GitLab Runner to Kubernetes cluster

GitLab gives you the ability to interact with Kubernetes clusters, and it also allows easy installation of applications that can be leveraged by your project.

In GitLab 10.6 we add the ability to deploy a GitLab Runner directly on your cluster with a single click. It will be automatically available to run jobs for your project, without any further configuration needed.

Quick deploy of GitLab Runner to Kubernetes cluster

Kubernetes cluster monitoring

Kubernetes provides a great way for developers to easily deploy and manage applications, without worrying about how or where their software is running. It is still important however to manage overall cluster capacity, to balance room for growth versus underutilized compute costs.

GitLab 10.6 makes this easy, by directly showing both the current and available compute resources for a connected cluster. For example if deploy boards is showing a pod that is failing to start, a user can simply check the cluster metrics to confirm if resources have been exhausted.

Kubernetes cluster monitoring

Ingress IP address on Kubernetes cluster page

In GitLab 10.2 we released the ability to install an Ingress in your Kubernetes cluster. Once installed, the Ingress provides a public IP address that allows external access to your deployed applications.

In GitLab 10.6, you can see the IP address assigned to your Ingress controller directly from the Kubernetes page in the UI, and use it to configure a domain name to access your applications from the internet.

Ingress IP address on Kubernetes cluster page

Maintainers can push to MR from fork

Forking workflows are common in open source projects like GitLab, where contributors submit merge requests from their fork of the project back to the upstream project.

When reviewing merge requests from forks, maintainers of the upstream project can now make small fixes or rebase before merging, reducing the back and forth of accepting community contributions. Of course, maintainers aren’t limited to small fixes and can help out by adding large commits to the merge request too!

Prior to this release, maintainers could not directly contribute to a merge request from a fork since maintainers do not automatically receive write permissions to forks. With this release, if the merge request author has write access to the source branch of the merge request, they can grant maintainers write access to the source branch of the merge request by enabling Allow edits from maintainers on the merge request. When enabled, users with merge permissions to the target branch of the upstream project will be able to push to the source branch of the merge request. By default, it is turned off.

Maintainers can push to MR from fork

Single Group Issue Board in Core and Free

GitLab’s Group Issue Board allows you to manage issues from multiple projects all at once. You can see issues from projects within the same group all within the same interface, and move them across workflow stages, all in one interface.

This feature was previously available exclusively in the Premium and Ultimate tiers. And users in these tiers have found it to be very useful. GitLab Core users have also asked for this feature, and they have said providing one group issue board would be a great addition to their workflows. So that’s what we have shipped in this release. Core and Starter instances now have one group issue board per group, and multiple group issue boards remain reserved for Premium and Ultimate. Correspondingly, Free and Bronze also have one group issue board per group, with multiple group issue boards continuing to be in Silver and Gold. We think this adds significant value to the Core and Free tiers, and helps even more users better evaluate and provide feedback on the feature itself.

Single Group Issue Board in Core and Free

Other improvements in GitLab 10.6

SAST security report on pipelines view

A few releases ago, we shipped Static Application Security Testing (SAST), which automatically finds vulnerabilities in any new code changes in a merge request. This allows you to fix them before merging, ensuring these security problems are not introduced nto master and not released to production.

With this release, this same information is available in a complete SAST security report in the CI/CD > Pipelines page. This allows developers, production/systems engineers, and any other security stakeholders to have even more visibility into any security risks as your code progresses through CI/CD.

SAST security report on pipelines view

External Authorization Control

In some regulated environments, project classification systems are used to control access to projects, and can now be used with GitLab. When enabled, admins can set the classification of each project. In addition to GitLab access controls, access to projects will also require approval from the external authorization service.

External CI/CD configuration in Starter and Bronze

In GitLab 10.5 we added the ability to include external CI/CD configuration files into the main .gitlab-ci.yml for your project. This feature was available only to Premium users on self-managed Gitlab and Silver users on

We received a lot of feedback from customers asking us to move this to a lower tier and we are excited to bring this feature to even more users in this release by making it now available to Starter users on self-managed Gitlab and Bronze users on The ability to have a centralized control over the pipeline configuration and to reuse the same definition in multiple projects is something that is valuable for enterprises and smaller businesses as well.

Note that as part of our commitment to open source, public projects on Free have features equivalent to a Gold level subscription. So those public projects will continue to have this feature.

Some teams use GitLab integrated with an external issue tracker. For example, Jira issues integrated with GitLab merge requests is a popular workflow for many teams. In this scenario, GitLab issues still function as normal, and teams are free to use them, for example, in separate one-off scenarios where a team wants everything just in GitLab.

To streamline this integration, we’ve added a new link to the project navigation. If you have configured any external issue tracker (Redmine, Jira, Bugzilla, or the Custom Issue Tracker), there will be a separate link in the project navigation that allows you to quickly navigate to that external system. The GitLab issues link remains so that there’s no confusion and also allows you to use both issue trackers if you want.

Navigate to external issue tracker

Labels in Epics

GitLab issues and merge requests support labels to enable flexible and highly customizable management of these objects. It’s an effective design that we’ve also brought to Epics in this release.

You can now assign group labels to epics from the sidebar of an epic, exactly the same as with issues and merge requests. And you can filter by labels on the epics list page in a group, again like issues and merge requests. Users of GitLab will thus find this feature immediately recognizable. This allows you easily mix and match epics into different categories based on the powerful search and filter bar.

Labels in Epics

Epics API

Along with the labels support mentioned above, we have maintained parity with API support for Epics. You can get a list of epics based on the same search and filter parameters of the search and filter bar in the web UI of the epics page. This includes searching by the epic title and description, filtering by the author and labels, and ordering by “created at” and “updated at” timestamps.

Discussions API

With this release, we have brought API support to discussions in issues, snippets, and epics. This means that all comments and discussions (for issues) are now accessible via the API. Teams can leverage this API for flexible, customized, and specific workflows that are not necessarily in the main GitLab web UI.

API support for comments and discussions in merge requests will also come in a future release.

Filipino, Indonesian, and Turkish language support

As part of our ongoing effort to internationalize GitLab, we have now added support for Filipino, Indonesian and Turkish translations.

We have also externalised strings on the Repository Locked Files (Premium and above) list page allowing our translation community to add more languages and strings to GitLab.

If you are interested in contributing to GitLab’s internationalization efforts, we welcome you to join our translation community.

GitLab Runner 10.6

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

Most interesting changes:

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

SAST for Java-Maven apps

Prior to this release, GitLab already supported popular languages such as Ruby, Python, and JavaScript as part of Static Application Security Testing (SAST) feature.

In GitLab 10.6, we are adding Maven, a common build automation tool for Java. If you are already using SAST, you don’t need to change anything in your configuration to get the new checks; they will be automatically available.

See the complete list of supported languages and frameworks.

SAST for Java-Maven apps

Authentication support for DAST

A few releases ago, we shipped Dynamic Application Security Testing (DAST), allowing you to check for security vulnerabilities dynamically and automatically in a Review App version of your work-in-progress code, before it is merged into master and released to production.

Previously, this feature was limited to public pages. With this release, you can now specify credentials that DAST will use to authenticate into your web app and to simulate an attacker that is able to access sections protected with a login process.

Authentication support for DAST

Branches overview

As projects and teams grow, so do the number of branches. The new branches overview and filtered branches lists make it easy to quickly find the branch you’re looking for. Branches with a commit added in the last three months are shown as active.

Thank you Takuya Noguchi for the contribution!

Branches overview

Project import/export API

Projects are extremely important in GitLab, since they contain all the valuable work (including the Git repo) and organization (including issues and merge requests) of your team. Using the existing project export and import features of GitLab, projects can easily be transferred within and between instances.

Up to now, this was a manual process. With this release, project exports and imports are now part of the GitLab API, allowing you even more automated and flexible workflows when you need move your projects within or between GitLab instances.

Thank you Travis Miller for the contribution!

GitLab ChatOps (alpha)

For many organizations, much of their communication, including their operations and troubleshooting discussions, is moving to chat. There is also typically an “operations toolbox,” containing frequently used commands to check on the health of an environment or to perform routine actions.

With GitLab 10.6 we wanted to make it easy to both automate these routine actions, as well as bring them into Slack itself. Getting started is as easy as adding a job to your GitLab CI YML, and enabling Slack slash commands integration. Users will then be able to interact with it by typing in the slash command, the CI job name, and then passing any relevant arguments. The job will be executed on a runner, with the output being sent right back to Slack.

Merge Request Approvals API

Prior to this release, the Merge Request Approvals API was limited to approving and unapproving a merge request only. With this release, you can now fully configure approvals at the project level and at the merge request level, giving users feature parity with the GitLab web UI.

With the Approvals API, teams can now create more elaborate code review and approval workflows that are specific to their needs. You can use as much or as little of the API as needed to customize which parts of your workflow happen inside the GitLab web UI, and which parts happen outside.

Business and other custom metrics

Since GitLab 9.0, developers have been able to monitor critical system and response metrics of their deployed apps, like throughput, latency, and CPU/memory utilization.

This provided a great baseline understanding of both the user experience your customers were receiving as well as resource utilization, directly in the tool they use every day.

With GitLab 10.6 we have added the ability to add your own metrics, allowing deeper introspection of your application and business. For example metrics from a credit card processing module can be added, tracking not just success rates but also revenue and order size. This can help surface failures that may not result in HTTP errors, as well as the ultimate impact on business performance.

To get started, simply provide the Prometheus PromQL query and it will begin to display in the dashboard.

Business and other custom metrics

Cloud native GitLab Helm chart (alpha)

We are excited to announce that the cloud native GitLab Helm chart is now in alpha, and available for testing. This chart features a more cloud native architecture, with a container for each component of GitLab and no requirement for shared storage. These changes result in increased resilience, scalability, and performance of GitLab on Kubernetes.

It is important to note that the chart and containers are still in active development, contain known issues and limitations, and should not be used for production. For this release GitLab Premium is required, while we work to bring Object Storage support to Core.

Omnibus improvements

  • GitLab Mattermost 4.7 includes enhanced image preview and thumbnails, faster load times, upgraded desktop app, and security updates. Upgrading is recommended.
  • Chef has been updated to 13.6.4
  • Omnibus has been updated to 5.6.10.
  • PostgreSQL has been updated to 9.6.8.
  • Python has been updated to 3.4.8.
  • jemalloc has been updated to 5.0.1.
  • announce-ip and announce-port are now configurable for Redis/Sentinel, to better support HA in Docker environments.


Mattermost configuration changes

With the release of GitLab 11.0, the number of Mattermost configuration options supported within gitlab.rb will be reduced. We will continue to support the core configuration settings necessary to run Mattermost, and set up the integration with GitLab. Going forward, other configuration settings should be set directly within the Mattermost console, or passed as environment variables.

Presently with two applications attempting to write to the same config file, changes can be lost.

Planned removal date: GitLab 11.0.

The legacy gitlab Helm chart

The legacy gitlab Helm chart is deprecated. For installations on Kubernetes today, we recommend the beta gitlab-omnibus Helm chart.

A new cloud native GitLab chart is in development with increased scalability, resilience, and other benefits. This chart will replace both existing charts when generally available later this year.

For more information on GitLab Helm charts, please read the documentation on installing GitLab on Kubernetes.

Planned removal date: March 22, 2018.

Removals and breaking changes

The complete list of all removed features can be viewed in the GitLab documentation.

Upgrade barometer

To upgrade to GitLab 10.6 from the latest 10.5 version, no downtime is required.

For this release we have migrations and post-deploy migrations. migrations took approximately 30 minutes and post-deploy migrations accounted for about 10 minutes.

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


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


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


Check out our update page.


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

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 free license

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 Free
Open in Web IDE View source