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!
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.
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).
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.
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.
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
John, but allow all
masters or even
developers to merge through a merge request to the branch.
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.
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.
We keep track of how many discussions you still need to resolve and added a convenient button to jump to the next unresolved discussion.
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:
Simply click on a pipeline in your merge request or pipelines view to view the graph for the current pipeline.
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.com, GitLab CE, and EE.
Templates are Markdown files (
.md) that live in the repository in a
.gitlab directory and either the
.gitlab/merge_request_templates subdirectory. They will appear in a dropdown when creating a new issue or merge request:
This should make it easier for everyone to submit good-looking feature requests, bug reports, and merge requests.
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.
Use them in comments or even when creating a new issue or merge request:
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.
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 GitLab.com at present.
Enable Koding in Admin > Application settings:
Set it up for your project:
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.
We've put together a quick screencast showing this off:
You can read more about setting up Koding in GitLab in our documentation.
You will now see your Pipelines in merge requests!
Click on a pipeline to see its graph and related builds.
You can now easily set the URL of your environments:
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:
With the URL configured, GitLab will link to the environment, so you can see the result of a merge request with a single click.
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
The editor in GitLab now properly highlights code and allows you to collapse blocks of code.
You'll now see a link to quickly create a new merge request and any related merge requests when you push to GitLab.
GitLab can now generate a nice looking coverage badge, so you can easily show off the test coverage of your projects anywhere:
If you didn't know GitLab could report coverage yet, set it up in your pipelines settings:
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.
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.
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 GitLab.com (the drop is the deploy).
Loading times of merge request diffs:
The number of SQL queries executed when displaying merge request diffs:
The time spent in SQL queries when displaying merge request diffs:
Pipelines performance also improved significantly:
See below for detailed improvements and the merge requests of the implementations.
ci_runnerstable have been removed: !5755
DiffHelperhave been removed: !5756
geo_nodestable has been removed: !639
Repositoryclass has been instrumented: !5621
Gitlab::Highlighthas been instrumented: !5644
Project.visible_to_userhas been instrumented again: !5793
We are also releasing GitLab Runner 1.5 today. A few highlights:
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.
GitLab now has experimental support for Redis Sentinel.
This release has more improvements, including security fixes. Please check out the changelog to see all the named changes.
To upgrade to GitLab 8.11, downtime is required due to migrations.
The downtime for GitLab.com (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.
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.
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:
apt-get update and
apt-get install gitlab-ce /
apt-get install gitlab-ee again to solve this issue.
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.
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
If you are setting up a new GitLab installation please see the download GitLab page.
Check out our update page.
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.