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
Global Code Search (EE)
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.
Merge Request Versions
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
Preventing Secrets in your repositories (EE)
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
Review Apps (Experimental)
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.
SSH Authentication for LFS
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.
Limit Project Size (EE)
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
LDAP/Active Directory Improvements
This release contains several improvements to LDAP/Active Directory support for GitLab CE and EE:
- CE/EE - Request only the LDAP user/group attributes that GitLab requires (CE !6187 and EE !712), reducing the amount of data across the wire between GitLab and the LDAP/Active Directory server. This also decreases the object memory footprint within GitLab.
- EE - Faster Active Directory nested group and ranged member (large group) retrieval (!719)
- EE - Add 'Sync now' option to group membership page when LDAP group links are present (!704)
Recover 2FA tokens through SSH
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.
Filter Tags by Name
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:
- Allow to set
request_access_enabledfor groups and projects using API
- Add a
- You can now fork to a specific namespace through the API
- Allow to set enable/disable access request for groups and projects.
web_urlfield to issue, merge request, and snippet objects. (community contribution)
merge_commit_shain merge request API. (community contribution)
- Expose issue confidentiality flag. (community contribution)
only_allow_merge_if_build_succeedsproject setting. (community contribution)
- Add endpoint to lint your
.gitlab-ci.ymlfile. (community contribution)
- Add an API to list manual actions on Environments and Deployments
Improved GitHub Importer
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.
Bulk update Merge Requests
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.
Expanded syntax highlighting
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.
Sentry integration of Workhorse
GitLab-Workhorse can now report application errors to Sentry.
GitLab Runner 1.6
We are also releasing GitLab Runner 1.6 today. Some highlights:
- Kubernetes executor (!30 and !277), this allows Kubernetes to automatically scale the number of CI runners. All your builds will be processed immediately without having idle machines running when it's not busy.
- Autocompletion of /ci in GitLab URL while registering the Runner (!289)
- Configuration options for specifying scripts executed before clone/fetch is done and before build script is executed (!106)
- Improvements in passing CA certificates to builds (!299)
- Improvement in disabling recursive submodules fetching/cloning (!314)
- Improve docker machine logging (!234)
- Add possibility to specify a list of volumes to inherit from another container (!236)
- Generate a
SystemErrorwhen Docker/Kubernetes image is missing (!295)
To see the full list of all changes please read the Runner's CHANGELOG file.
GitLab Mattermost 3.4
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.
- Sidekiq processes now use a connection pool when using Rails' caching mechanism: merge request
ojGem is now used for faster JSON processing: merge request
- The column
projects.last_activity_atis only updated once an hour to reduce database load: merge request
- The column
projects.pushes_since_gchas been moved from the database to Redis to reduce database load: merge request
- Protected branch checks are not performed when no branch name is known, reducing time spent in this process: merge request
- Checking if one can resolve a note is only done when notes can be resolved in the first place: merge request
ci_runnerstable is now updated less frequently to reduce database load: merge request
- The number of database queries used for the "Builds" tab for commits/merge requests has been reduced: merge request
- The payload size for the contributions calendar has been reduced: merge request
Build permissions changes
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:
- We already have a permission system in place: group and project membership of users.
- We already know who is triggering a build (using git push, using web, executing triggers).
- We already know what that user is allowed to do.
- We use the user's permissions for builds that are triggered by pusher.
- It is simple and convenient that your build can access everything that you have access to.
- We can issue a short-lived unique tokens, granting access for the duration of the build.
- It fits very well into our philosophy of having everything integrated.
- This provides a lot of possibilities to further enforce user permissions, such as allowing only specific users to access runners, secure variables and environments.
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 in CI
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 = firstname.lastname@example.org/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.
(EE Only) Elasticsearch re-indexing
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.
Expanded usage data ping (EE)
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 Secret Key
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.