Whether you're working on a small or a large project, your tools should get out of your way and give you actionable feedback. This month, we're making sure GitLab does both better than ever.
GitLab 8.12 gives you feedback on how efficiently you actually work, helps you find code across the entire instance, makes your workflow much safer with a single click, and much more.
This month's Most Valuable Person (MVP) is James Munnelly for contributing the Kubernetes executor in the GitLab CI runner. This feature allows users to run CI tests in a Kubernetes cluster easily. James created this merge request over a year ago and showed great patience and persistence in the review process to see it to completion. Thanks, James!
Reducing cycle time, the time it takes you to go from idea all the way to production, is the first principle of conversational development. The shorter the cycle time, the higher the efficiency of your team.
In order to make it possible to actually see what your cycle time is, we're introducing Cycle Analytics with GitLab 8.12.
Cycle Analytics tells you what your cycle time is and breaks it down into several steps, so you can quickly see where to improve and accurately predict when you're shipping something.
Find Cycle Analytics under Pipelines in all your projects.
Read more in the documentation for Cycle Analytics
If you're running Elasticsearch on your GitLab Enterprise Edition instance, you will now be able to search through all code on the server!
Just use the search as before and GitLab will show you matching code from each project you have access to.
Note that this change requires that you rebuild your Elasticsearch index. See the upgrade barometer below for more information.
When you're pushing more than a single commit to a merge request, it can be hard to view what changed between versions and the target branch.
With merge request versions you can view previous states of a merge request: compare between a previous commit and the target branch or even between versions, showing you what has changed between certain commits.
Read more in the documentation for Merge request revisions
It's a bad idea to commit secrets (such as keys and certificates) to your repositories: they'll be cloned to the machines of anyone that has access to the repository, only one of which has to be insecure for the information to be compromised.
Yet it happens quite easily. You write
git commit -am 'quickfix' && git push and suddenly you've committed files that were meant to stay local!
GitLab now has a new push rule that will prevent commits with secrets from entering the repository. Just check the checkbox and GitLab will prevent common unsafe files such as
.key from being committed.
GitLab Enterprise Edition already had a feature that allows you to block files based on a regular expression, which you can leverage to block anything that we didn't think of. We also welcome suggestions and contributions to make this push rule even better.
Read more in the documentation on Push rules
We've made several additions to CI that, when combined, make some magic.
You can now use predefined CI variables as a name for environments. In addition, you can specify a URL for the environment configuration in your
.gitlab-ci.yml file. Together, these features bring the first iteration of Review Apps.
Review apps are automatically-created environments that run your code for each branch. That means merge requests can be reviewed in a live-running environment. This was inspired by Heroku's Review Apps which itself was inspired by Fourchette.
These are small changes, but will make a huge impact on your development flow. Reviewing anything from performance to interface changes becomes much easier with a live environment.
Right now, Review Apps are labelled experimental, as the environments are not automatically destroyed when no longer necessary.
We're working on a blog post that will have an example.
If you're used to using SSH for your Git pushes, it was frustrating to still have to enter credentials whenever using LFS.
GitLab will now leverage your SSH key when using LFS, meaning that if you're using LFS while connecting through SSH, you no longer have to manually enter your credentials!
File transfers of LFS still happen over HTTP.
Git LFS (Large File Storage) is great, but as the name implies, it can have significant impact on your disk capacity. To make you feel a bit more secure about the LFS usage on your instance, you can now toggle LFS on instance, group, and project levels.
For instance, as a GitLab administrator, you can decide to turn off LFS for the entire instance, yet enable it for only a single group or project.
As an alternative to restricting LFS, you might just want to prevent projects from growing too large. You can now limit project size. This will take into account all repository data and LFS objects and stop any commits that will surpass that limit.
You can set a global project limit and override that on group and project level, as an admin. This way, you can give particular projects extra space if necessary.
Read mote in the documentation about limiting the repository size
This release contains several improvements to LDAP/Active Directory support for GitLab CE and EE:
You can now recover your 2FA security codes using SSH. This should make it easier to recover your account, while still maintaining a level of security.
Read more in the documentation about recovering 2FA via SSH.
Want to quickly find a tag? That's much easier now with a handy little filter on top:
We've expanded our API on several points with GitLab 8.12:
request_access_enabledfor groups and projects using API
web_urlfield to issue, merge request, and snippet objects. (community contribution)
merge_commit_shain merge request API. (community contribution)
only_allow_merge_if_build_succeedsproject setting. (community contribution)
.gitlab-ci.ymlfile. (community contribution)
Our GitHub importer keeps getting better, making it easier to migrate to GitLab. With GitLab 8.12, the importer will also copy release notes over to GitLab and now lets you choose the namespace you want your imported projects to go into.
This should make it easier to migrate if you already have existing projects or prefer something different than GitLab's way of importing your projects.
Read more in the documentation about importing your repositories from GitHub.
You can now bulk update merge requests. This means you can set the status, assignee, milestone, label or subscription to multiple merge requests at once.
Managing merge-request-heavy project should be a lot easier with this!
If you have many similar builds, your pipeline graph becomes very long. We've made a small change to improve this: similar builds will now automatically group together.
By upgrading to rouge 2.0.6, we've added syntax highlighting for JSX, Prometheus, mxml, 1c, turtle/trig, vhdl, and improved highlighting for Swift 3.
GitLab-Workhorse can now report application errors to Sentry.
We are also releasing GitLab Runner 1.6 today. Some highlights:
SystemErrorwhen Docker/Kubernetes image is missing (!295)
To see the full list of all changes please read the Runner's CHANGELOG file.
GitLab 8.12 includes Mattermost 3.4, an open source Slack-alternative whose newest release offers 700 integrations with full Markdown support via Zapier, simplified bot and 3rd party authentication via OAuth2, and community integrations with Gitter, Heroku, Pivotal Tracker, Chef, Ansible and Yunohost.
ojGem is now used for faster JSON processing: merge request
projects.last_activity_atis only updated once an hour to reduce database load: merge request
projects.pushes_since_gchas been moved from the database to Redis to reduce database load: merge request
ci_runnerstable is now updated less frequently to reduce database load: merge request
GitLab 8.12 brings very important changes to build permissions.
We decided that build permissions should be tightly integrated with the permissions of the user triggering a build for the following reasons:
Now, any build that was triggered by the user is also signed with his permissions. When a user does
git push or modifies files through the UI (the pusher), we will create a new Pipeline. The Pipeline will be owned by the pusher. So builds created in this pipeline will have the permissions of the pusher.
This allows us to make it easy to evaluate access for all dependent projects and container images that the pusher would have access too. The permission is granted only for the duration of the build. The access is revoked after the build is finished.
For detailed information about the build permissions and the changes it brings please see our documentation.
For the history and reasoning behind this change, you can read the full discussion in the issue.
Submodules were one of the reasons we redesigned the build permissions. Now using Submodules in your CI builds is easy.
To use submodules you have to use a
.gitmodules file, which looks something like this:
[submodule "tools"] path = tools url = email@example.com/group/tools.git
To use the new build permissions for your submodules you have to convert your URLs to be relative:
[submodule "tools"] path = tools url = ../../group/tools.git
This will instruct Git to use the same credentials as it would for checking out your project sources.
The last step is to tell GitLab CI to fetch submodules:
before_script: - git submodule update --init --recursive
You can read more about support for submodules in our documentation.
This release has more improvements, including security fixes. Please check out the Changelog to see the all named changes.
This release requires downtime due to foreign keys being added, column types being changed, and various columns being removed from some tables. The whole migration process could take up to 30 minutes for large instances. Smaller instances should expect a downtime of about 10-15 minutes.
We changed the structure of Elasticsearch index for repositories, making use of Parent Child relationships. This requires a total rebuild of the ES index. Also Elasticsearch 2.3.x contains a bug that causes to fail all queries that use highlight feature and Parent Child relationship at once, so we recommend to use the version 2.4 and newer. After upgrading to GitLab 8.12, you will need to remove the old index and rebuild new index:
To remove the old index, call to Elasticsearch:
curl -XDELETE 'http://localhost:9200/gitlab-production/'
Then rebuild new indexes as described in Elasticsearch integration
In our last release blog post we mentioned we'd be dropping Ruby 2.1.x support in GitLab 8.13, we no longer plan to stop supporting Ruby 2.1.x in the near future.
We still recommend you upgrade to Ruby 2.3 if you're running a source installation, as this is the same version that ships with our Omnibus package now.
In order to better understand the usage of GitLab by our customers, GitLab 8.12 EE now sends additional data along with its usage ping.
No information about the nature of the data, such as project names, comments or other content is transmitted. You can view the exact data that is sent in the admin settings, where this feature can also be disabled entirely.
GitLab-Workhorse now uses a secret key to sign certain messages sent to the GitLab Rails application. For now this is mostly a configuration sanity check; in future releases we want to add features to GitLab-Workhorse that require this secret key to establish trust.
If you use our Omnibus packages, or if you installed GitLab from source with our official init.d script, then this secret key will be generated and picked up automatically for you. If you use a custom init.d script or if you use packages not created by GitLab Inc. then you may have to set the
-secretPath option on GitLab-Workhorse.
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.