GitLab 8.11 released with Issue Boards and Merge Conflict Resolution

Aug 22, 2016

There are so many good things in GitLab 8.11, that I struggle to introduce all this without turning to superlatives. So, without further ado:

With GitLab 8.11 you get a completely new way to manage your issues, you can resolve merge conflicts in the interface, you can restrict pushes to people and groups (in EE), you get an online IDE, you can use slash commands to modify issues and you can create as many issue templates as you want ..and many other new features.

This month's Most Valuable Person (MVP) is Clement Ho for his merge requests and responsiveness on issues. Thanks Clement Ho!

Issue Board

GitLab Issues are very flexible. You can crosslink them, prioritize them, and rank them by popularity. With the Issue Board we've added something new:

You can now create workflows, quickly get an idea of the status of your issues and all that in a simple, beautiful Board, not unlike a Kanban or Scrum board.

Issue Boards in GitLab 8.11

You have a board for every project, which starts with a Backlog with all open issues and a Done list, where issues are automatically closed.

By adding new lists you can create workflows. Lists are based on labels, this means that adding an issue to a list will add that label to the issue and removing it from a list, will remove the label.

This means all your current issues will automatically appear in new lists you create and that you can quickly see whether a certain issue is in one (or more!) of the lists.

To see an example, have a look at the GitLab CE Issue Board for the next release (8.12).

Issue Board Documentation

Merge Conflict Resolution

Merge conflicts can be a real pain when you want to get something to merge in a busy project. We believe you shouldn't need any external tools to fix your conflicts, which is why you can now solve simple conflicts straight from GitLab.

Merge Conflict Resolution in GitLab 8.11

When you encounter a conflict, you simply click "Resolve these conflicts" to be able to select how you want the conflicts to be resolved. You confirm at the end to make a commit with your fix.

We realize that this won't work for all conflicts, but hope that this will make the majority of your conflicts minor bumps in the road to getting your work to production.

Resolve conflicts Documentation

Branch Permissions for Users (EE only)

It's now possible to restrict pushing and merging to specific branches to specific users, using Branch Permissions in GitLab Enterprise Edition.

This works hand-in-hand with the existing functionality and can easily be combined with our restrictions. This means that you can restrict direct pushes to only Jane and John, but allow all masters or even developers to merge through a merge request to the branch.

Branch permissions for users in GitLab 8.11

For each action (push and merge) you can allow any amount of users and permissions, making this a very powerful addition to GitLab EE for organizations.

Branch permissions for users Documentation

Resolve Discussions in MRs

Discussions on diffs in merge requests can be hard to keep track of, yet it's important that you actually give each comment attention.

To make it easier to find, fix, and resolve those comments and discussions, we've added the ability to do just that: Each comment and discussion on merge request diffs can be resolved. Longer threads can be resolved all at once or just comment-by-comment.

Resolve Discussions in GitLab 8.11

We keep track of how many discussions you still need to resolve and added a convenient button to jump to the next unresolved discussion.

Jump to the next unresolved discussion in GitLab 8.11

Merge request discussion resolution Documentation

Pipelines Graph

Pipelines in GitLab can be complex structures with many sequential and parallel builds. To make it a little easier to see what is going on, you can now view a graph of a single pipeline and its status:

Pipeline Graphs in GitLab 8.11

Simply click on a pipeline in your merge request or pipelines view to view the graph for the current pipeline.

Issue and MR Templates

To standardize on a certain format for issues and merge requests, you could already create templates in GitLab Enterprise Edition.

With GitLab 8.11, we're bringing the ability to create multiple templates (for instance, one for feature proposals, another for bugs) to, GitLab CE, and EE.

Templates are Markdown files (.md) that live in the repository in a .gitlab directory and either the .gitlab/issue_templates or .gitlab/merge_request_templates subdirectory. They will appear in a dropdown when creating a new issue or merge request:

Issue and Merge Request templates in GitLab 8.11

This should make it easier for everyone to submit good-looking feature requests, bug reports, and merge requests.

See the documentation on templates

Slash Commands

Inspired by chat tools, such as IRC, HipChat, Mattermost, and Slack, we've added our own version of slash commands to GitLab. This means you can quickly change labels, milestones, assignees and more by just writing a comment or by having a command when writing your merge request or issue.

Slash commands in GitLab 8.11

Use them in comments or even when creating a new issue or merge request:

Slash commands in GitLab 8.11

You can have multiple commands in a single comment and do things like changing the title of an issue, adding or removing labels and changing assignees.

Here are some ideas on using the new slash commands:

We can't wait to see how you'll use them.

Slash commands Documentation

Koding Integration

Koding allows you to run your entire development environment in the cloud, share it with your team, and even use your local editor. This means that you don't have to spend hours setting up your stack on every new machine and every change.

With GitLab 8.11, we're introducing the Koding integration with GitLab. This means that you can check out a project or just a merge request in a full-fledged IDE with the press of a button. The Koding integration is not on at present.

Enable Koding in Admin > Application settings:

Koding, an integrated IDE in GitLab 8.11

Set it up for your project:

Koding, an integrated IDE in GitLab 8.11

Koding, an integrated IDE in GitLab 8.11

And now you're able to quickly check out any merge request, branch, and commit in a complete IDE, that even allows you to use your local editor.

Koding, an integrated IDE in GitLab 8.11

We've put together a quick screencast showing this off:

You can read more about setting up Koding in GitLab in our documentation.

Pipelines in MRs

You will now see your Pipelines in merge requests!

Pipelines in merge requests in GitLab 8.11

Click on a pipeline to see its graph and related builds.

Deployment status in Merge Requests

You can now easily set the URL of your environments:

Set the URL of any environment in GitLab 8.11

Which helps if you deploy automatically after a merge request is merged, as now GitLab will show the state of the deploy in your merge requests:

See deploy status in merge request in GitLab 8.11

With the URL configured, GitLab will link to the environment, so you can see the result of a merge request with a single click.

Pipelines Web Hooks

To make it easier to integrate the power of GitLab's pipelines, we've added a webhook for pipelines. It'll fire whenever a pipeline is created, is running or is finished.

Enable any webhooks by going to the settings dropdown in your project and selecting Webhooks.

Code Highlighting and Collapsing

The editor in GitLab now properly highlights code and allows you to collapse blocks of code.

Code highlighting in GitLab 8.11

You'll now see a link to quickly create a new merge request and any related merge requests when you push to GitLab.

Merge request links when pushing in GitLab 8.11

Coverage badge

GitLab can now generate a nice looking coverage badge, so you can easily show off the test coverage of your projects anywhere:

Coverage Badge in GitLab 8.11

If you didn't know GitLab could report coverage yet, set it up in your pipelines settings: pipelines/settings.

Read the docs on test coverage badges

Expiration date on Memberships

When giving a user access to a project or when sharing a project with a group, you can now limit that access to a certain date, setting an expiration date. After the date, the user or group will no longer have access to the project.

This should make it easier to manage sharing projects with temporary team members.

Move projects between shards (EE only)

With GitLab 8.10 we introduced multiple mount points in GitLab.

With GitLab 8.11 you can move projects between shards with a rake command. This is not something for everyday use, but it is convenient if you want to test a new shard or want to move that super-heavily used project over to faster storage.

Performance Updates

In this release we've added another batch of significant performance improvements.

Merge requests and their diffs are faster! Below some graphs that show the difference for when we deployed GitLab 8.11 RC2 to (the drop is the deploy).

Loading times of merge request diffs:

Performance improvements in GitLab 8.11

The number of SQL queries executed when displaying merge request diffs:

Performance improvements in GitLab 8.11

The time spent in SQL queries when displaying merge request diffs:

Performance improvements in GitLab 8.11

Pipelines performance also improved significantly:

Performance improvements in GitLab 8.11

See below for detailed improvements and the merge requests of the implementations.




GitLab Runner

We are also releasing GitLab Runner 1.5 today. A few highlights:

GitLab Mattermost 3.3

GitLab 8.11 includes Mattermost 3.3, an open source Slack-alternative whose newest release includes Chinese, Korean and Dutch translation, a Golang bot, flagged posts, @here mentions, plus many more new benefits.

This version also includes security updates and upgrade from earlier versions is recommended.

Redis Sentinel Support

GitLab now has experimental support for Redis Sentinel.

See the docs for details

Other changes

This release has more improvements, including security fixes. Please check out the changelog to see all the named changes.

Upgrade barometer

To upgrade to GitLab 8.11, downtime is required due to migrations.

The downtime for (the largest GitLab instance) was about 15 to 30 minutes. It may take less time depending on the amount of data on your instance.

Some columns are removed by one migration which may affect users running a version of GitLab that was still using said column. Two other migrations populate newly created tables based on existing data, as such they require downtime to ensure this data isn't modified while the migration is running (and until 8.11 is deployed to the user's cluster). Finally another migration adds two foreign keys, which requires downtime as this is not done in a concurrent manner.

Ruby 2.1 deprecation

With this release of GitLab, we're upgrading to Ruby 2.3. For manual installations, we strongly suggest you update Ruby to 2.3 with this release. Omnibus installations will be automatically on Ruby 2.3.

Note for early updaters

If you were very fast in updating GitLab to 8.11 and during reconfigure received undefined method merge! for nil:NilClass error, make sure that you fetch the newer package marked with .1: 8.11.0-ce.1.

Simply run apt-get update and apt-get install gitlab-ce / apt-get install gitlab-ee again to solve this issue.

2FA enforced through API and Git over HTTP

Users with 2FA enabled trying to retrieve an API token via the /sessions endpoint or the Resource Owner Password Credentials flow provided by OAuth2, will not be able to login. They will be required to use a Personal Access Token from now on.

Read our documentation on personal access tokens

(EE Only) Elasticsearch reindexing

We changed the structure of Elasticsearch indexes, making use of parent/child relationships. This has performance advantages, but requires a total rebuild of the ES index. After upgrading to GitLab 8.11, you will need to remove the old indexes and rebuild new indexes:

To remove the old indexes, call to Elasticsearch:

curl -XDELETE 'http://localhost:9200/_all/'

Then rebuild new indexes as described in Elasticsearch integration

Note We assume you are upgrading from the latest version. If not, then also consult the upgrade barometers of any intermediate versions you are skipping. If you are upgrading from a GitLab version prior to 8.0 and you have CI enabled, you have to upgrade to GitLab 8.0 first.

Please be aware that by default the Omnibus packages will stop, run migrations, and start again, no matter how “big” or “small” the upgrade is. This behavior can be changed by adding a /etc/gitlab/skip-auto-migrations file.


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


Check out our update page.

Enterprise Edition

The mentioned EE only features and things like LDAP group support can be found in GitLab Enterprise Edition. For a complete overview please have a look at the feature list of GitLab EE.

Access to GitLab Enterprise Edition is included with a subscription. No time to upgrade GitLab yourself? A subscription also entitles you to our upgrade and installation services.

Install GitLab on your own server in 2 minutes

Browse all posts

For the latest and most detailed news follow @gitlab on Twitter. Future blog posts suggestions.