With this last release of the year, we're not only completing our Master Plan, but we want to show you something cool we've been working on:
With GitLab 8.15, we're introducing Auto Deploy (shown in the video at 1:42), which automates setting up deploys and review apps. For a Ruby on Rails project, this brings setup time to under a minute.
Plus, to make accessing your environments easier and faster, you can now access them directly through a terminal in GitLab (shown in the video at 5:18).
We want to give the power of containers, continuous integration and deployment, review apps and container schedulers to everyone. With GitLab 8.15, we take away all the hard work without hiding anything. In the demonstration we set up and deploy a Ruby application with review apps, multiple environments, chatops to a Kubernetes cluster in about 12 minutes. This typically takes days, if not weeks to set up and use without GitLab.
For many people, December is a month of celebration and gift giving. This month, GitLab was again so lucky to receive many great contributions.
The MVP of this month is Michael Munch for bringing beautifully-typeset math (LaTeX) to GitLab. Michael worked over a period of 6 months in merge requests with in total more than three hundred comments to bring this to GitLab.
We'd also like to thank Warren Postma for his contributions on the issue trackers, and the community forum and generally being a great advocate of the product and the company. And lastly, we want to thank Elan Ruusamäe and Dirk Hörner for their contributions in technical design and implementation that have given super powers to Git Hooks.
Thanks Warren, Michael, Elan, and Dirk!
We want everyone to quickly get a fully functioning CI/CD pipeline that deploys to a container scheduler. It shouldn't require any effort to get started, but should also be scalable and not hide any of the magic.
Auto Deploy does this. Auto Deploy adds a single button to your project, that when clicked, will create a merge request with a template that will automatically deploy your application using Docker to your container scheduler. The cool thing about this is that this immediately leverages Review Apps, meaning you can see it working before even merging the merge request!
This is as close as you can get to one-click deploys, while exposing what is happening and having all this version-controlled, ready to collaborate and iterate on.
See 1:42 in the video for a quick demo of Auto Deploy, as it is available in GitLab 8.15.
For this first iteration, we ship Auto Deploy with a template for deploying to an external OpenShift cluster. We use Herokuish and Heroku Buildpacks to package your application into a Docker Image that then is deployed to Kubernetes on Openshift. We want to add support for more container schedulers and cloud platforms later (vanilla Kubernetes cluster, Mesos, Docker Swarm). Contributions are very welcome in our template repository.
See the Autodeploy documentation for more information.
Working together with your container scheduler, GitLab happily spins up several (dynamic) environments on request for your projects. Be that for review apps or a staging or production environment. Traditionally, getting direct access to these environments has been a little painful. And that's a shame: it's very useful to quickly try something in a live environment to debug a problem, or just to experiment.
With the web terminal, this has become extremely easy. Just visit the environments page in your project and click on the terminal button. GitLab will SSH into the instance for you and allow you to do anything you would be able to do from your local instance.
In the demonstration at 5:18 we show you give you a quick peek at the web terminal. We can't wait to see how you'll use it to speed up your workflow.
Improved Bitbucket Importer
Importing from Bitbucket has become even more powerful. With GitLab 8.15 we'll also import all pull requests as individual merge requests plus pull request comments, milestones and the wiki from Bitbucket. That makes the things we import from any Bitbucket project:
- Repository description
- Git repository
- Issues and their comments
- Pull Requests and their comments
When importing a project all references to pull requests and issues are preserved and so is the access level (public/private).
Global Git Hooks
If you want to enforce rules and triggers based on Git pushes and their contents, you have been able to use custom Git hooks in GitLab. But if you want to standardize on these rules, you'd have to copy and paste them to every new project.
With Global Git Hooks you can now create Git hooks that will be run for each project on the GitLab instance. This should make it much easier to set up rules that you want all incoming code to comply with.
Create the hooks in
hooks/<hook_name>.d/ directory or tell GitLab Shell where the directories are.
Chained Custom Git Hooks
If you have set up custom Git hooks, the order might matter: when an initial hook fails, there is no point in moving forward. With Chained Custom Hooks hooks will execute in lexical order, failing on the first failing script.
This means you can create hooks
2-hook.sh and you'll know that
1 will execute before
This gives a lot of power to your hooks and allows endless customization of what happens when a commit is about to land in your GitLab project.
For more information, see the custom git hooks documentation.
Thanks to both Elan Ruusamäe and Dirk Hörner for both helping to define Global Git Hooks and this feature, and providing the implementation!
LDAP Group membership overrides (EE)
In GitLab EE, you can sync any LDAP group with any GitLab group and give everyone automatically a certain permission. For instance, you can give everyone in the LDAP group
Developer permission level. New developers just have to be added to the LDAP group and GitLab will take care of giving them access automatically.
With GitLab 8.15, this has become even more powerful. In addition to the automatically synced permissions, you can now override this permission per user. This should make it easier to manage complex permissions across groups and projects.
After bringing Chatops to GitLab with our Mattermost integration, we're now doing the same for everyone using Slack! This means you can create, show and search for issues straight from Slack. Super convenient to bridge that gap from a casual conversation to an actual issue.
In addition, you can actually deploy from and to any environment. For instance, you can do
/awesome-website deploy from staging to production
And GitLab will deploy the latest commit from staging onto master.
Configure Chatops for Slack in your project services. As always, we're looking forward to see contributions to help expand the power of chat integration with GitLab!
One-click Mattermost configuration
The Mattermost and Slack integrations allow you to do the same things: create, show and search for issues and deploy to any environment.
Diff in Notification Emails
When you get a notification email from a comment on a diff, GitLab will now send along a bit of the diff, so you have the correct context immediately available.
Our amazing usability team has been working hard on making GitLab easier to use, enhancing GitLab's personality and improving readability. This release contains various changes that will make using GitLab more enjoyable!
To improve readability and cross-OS/browser support in GitLab, we have changed to using system fonts. These fonts are optimized for your platform and should therefore provide a better experience, independent of where you're viewing GitLab from.
If you want to get a feel of GitLab across platforms, check out the original merge request.
Slimmed down widths
We've reduced the max-width for issues and merge requests container in order to provide a more readable line length. This is the first step for us to correct the huge line lengths you see throughout GitLab. Follow our meta issue as we continue to improve GitLab's line length.
Improved Build Scrolling and Loading
Build scrolling and loading works and looks quite a bit better now:
Smaller page size
Between system fonts and improvements to autocomplete, we've reduced the average page size of any page in GitLab significantly. A given merge request in the GitLab CE project went from 1800kb to now 718kb!
Improved empty states
In order to improve our experience for users who are just getting started with GitLab, we've added informative and fun empty states to many of our pages across the application! View our meta issue to see where we've placed new empty states and feel free to suggest new ones!
Other changes and tweaks
- Improved accessibility by adding a focus state to dropdown options
- Added hover states to our primary navigation and tabs throughout the site.
- Improved hover, focus, and active states for buttons !7797
- Added hover states to collapsed items with the issues/mr's sidebar !7777
Mathematics support for Markdown and AsciiDoc, using KaTeX
Comments and repository files can now contain beautifully-typeset mathematics, using the KaTeX library from Khan Academy.
To render inline mathematics, use dollar signs around inline code:
To render multiline mathematics, use the
math language for the code block:
```math a^2+b^2=c^2 ```
In addition to working for Markdown, this is also available for AsciiDoc documents. Read the documentation on mathematics support.
Thanks to Michael Munch for this feature!
Cleaner merge commit messages
Previously, merge commit messages included the title and description of the merge request, and a reference to the merge request. This didn't read well when using
git log and similar tools, because merge request descriptions often contain requests for review, screenshots, and other details incidental to the code change.
Now, the default merge commit message is in the following format:
Merge branch '$SOURCE_BRANCH' into '$TARGET_BRANCH' $TITLE Closes $CLOSING_ISSUE_REFERENCES # only present if the MR closes issues See merge request $MERGE_REQUEST_REFERENCE
The previous default message is available as an option when customizing the merge commit message.
Thanks to Gabriel Gizotti!
Shorthand cross-project references in GitLab Flavored Markdown
Previously, a reference to something in another project always included the namespace, even if the project was in the same namespace.
Now, shorthand references are available. So from within the
gitlab-org/gitlab-ce project, you can refer to issue #1 in GitLab Workhorse by writing
gitlab-workhorse#1 instead of
gitlab-org/gitlab-workhorse#1, saving precious keystrokes!
For more information, see the special GitLab references section of our Markdown documentation.
Thanks to Oswaldo Ferreira!
Create an issue with unresolved discussion from a merge request
Now, we have added an option to create a new issue from the unresolved discussions in a merge request, and resolve those discussions at the same time! This is perfect for those cases where you need to merge something now, but don't want to forget about the code review comments.
Thanks to Bob van Landuyt!
Manual Actions from the Pipeline Graph
Manual actions allow you to require manual interaction before moving forward with a particular job in CI. Your entire pipeline can run automatically, but the actual deploy to production will require a click.
You can do this straight from the pipeline graph. Just click on the play button to execute that particular job.
User Activities API
To quickly get an idea of when a user last interacted with GitLab, we've added a special admin-only API to GitLab that allows you to get the last activity timestamp of every user on the instance.
Sort Project and Group members
You can now find people in projects and groups more easily by sorting them by name, access level and date of joining.
Every month we make many additions to our API. Here are the highlights for GitLab 8.15:
- Allow some Project API GET endpoints to be requested anonymously
- Allow Repositories & Files API GET endpoints to be requested anonymously
- Allow some Tag API GET endpoints to be requested anonymously
- Add scopes for personal access tokens and OAuth tokens
- Add ability to cherry pick a commit (community contribution)
- Add ability to unshare a project from a group (community contribution)
- Add ability to set
should_remove_source_branchon merge requests (community contribution)
- Add simple representation of group's projects (community contribution)
- Expose committer details for commits (community contribution)
- Expose merge status for branch API (community contribution)
- Expose personal snippets as /snippets (community contribution)
- Expose pipeline coverage
Omnibus GitLab package changes
PostgreSQL version upgrade
Starting last month with GitLab 8.14 omnibus-gitlab package, we are providing a way to upgrade the PostgreSQL database version.
The current version of PostgreSQL we are packaging (9.2.18) is slowly approaching its EOL. Due to the PostgreSQL versioning policy, upgrades between major releases require downtime and the use of the
For this purpose, we are packaging the newest available PostgreSQL version (9.6.1). We are also introducing
gitlab-ctl pg-upgrade tool which should make this transition as painless as possible. When upgrading to GitLab 8.15, this action will not be run automatically. This will allow you to plan the database upgrade downtime.
After version 9.0 is released, we plan on setting the PostgreSQL version 9.6 as default so please make sure that you plan your upgrade before that release. We're expecting to ship GitLab 9.0 on or after February 22nd.
- Retrieving commit counts has been improved for certain cases: !7668
- Polling intervals have been adjusted to reduce system load: !7762
- Refreshing authorized projects is done in a smarter way to reduce database load: !7956
- The most recent commit ID for a path is now cached: !8098
GitLab EE now ships with a command called
sidekiq-cluster. This command can be used to start extra Sidekiq workers that process only a limited number of queues. This feature can be used to process queues that receive a lot of jobs, without it affecting other parts of Sidekiq. This was added in 922.
This command is not yet used by Omnibus, our goal is to add this in 8.16.
GitLab Runner 1.9
We are also releasing GitLab Runner 1.9 today. Some highlights:
- Add a retry mechanism to prevent failed clones in builds !399
- Add Kubernete Node Selector !328
- Push prebuilt images to dockerhub !420
- Use prebuilt containers with Kubernetes executor !425
- Add path and share cache settings for S3 cache !423
- Split prepare stage to be: prepare, git_clone, restore_cache, download_artifacts !406
- Introduce docker.Client timeouts !411
- Allow network-sourced variables to specify that they should be files !413
- Fix docker hanging for docker-engine 1.12.4 !415
- Add pprof HTTP endpoints to metrics server !398
- Add a multiple prometheus metrics: !401
To see the full list of all changes please read the Runner's CHANGELOG file.
GitLab Mattermost 3.5.1
GitLab 8.15 includes Mattermost 3.5.1, an open source Slack-alternative providing workplace messaging for web, PC and phone with archiving and search. Improvements this month include new Xen Orchestra and Homebrew integrations, plus upgraded Desktop Apps for Windows, Mac and Linux.
This version includes security updates and upgrade from earlier versions is recommended.
Mattermost 3.5.1 was included in GitLab 8.14.1, so anyone on GitLab 8.14.1 or later should have the patch already.
This release has more improvements. Please check out the changelog to see all the named changes.
To upgrade to GitLab 8.15, downtime is required. Larger instances (>1000 users) should expect about 15 minutes of downtime.
The specific migrations requiring downtime are described below.
- Columns with default values are added, this process may take some time depending on the number of rows in these tables
- Some indexes are added concurrently, which does not require downtime but may take some time to complete
- The environments table is cleaned up, and a new column is added with a generated default value (this could take some time depending on the number of environments)
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.