May 22, 2018 - Jeremy Watson    
10.8

GitLab 10.8 released with incremental rollouts, plus open source push mirroring

GitLab 10.8 released with incremental rollouts, open source push mirroring, interactive security reports, group milestone burndowns, and much more!

We're super excited to share a host of awesome additions now available in GitLab 10.8! We've improved release automation, sped up security vulnerability remediation, open sourced a highly requested paid feature, and plenty more.

Deploy with confidence

Releasing new features always comes with a bit of anxiety. Even with stringent pre-release testing, a change to your production codebase can result in unforeseen effects. Our new Incremental Rollouts feature helps developers deploy code with confidence by exposing changes to only a subset of users. Instead of rolling out to your entire user base all at once, incremental rollouts lets you gradually deploy to an increasing portion of your Kubernetes pods. If problems do occur, you can roll back without affecting the entire user base. We're excited to provide an improved way to protect users and manage the unexpected, so you're free to deploy more frequently.

Push Mirroring is now open source

When we first released Push Mirroring, it was introduced as a paid feature. Since then, it has been one of the features that is most requested to be moved into our open source codebase. We take these requests seriously, and view having a balance between paid and open source features as good stewardship. Today, we're happy to share that Push Mirroring has been open sourced!

This opens up a few key use cases for GitLab Core users including freelance development and migration. Freelance developers can now mirror each of their clients repos. While folks migrating to GitLab from other git-based repositories can now take advantage of push mirroring to ease the migration path.

Whenever possible, we like to open source features to not only encourage greater usage of GitLab, but also to encourage more folks to contribute to open source software.

Ship securely faster

Keeping track of vulnerabilities without automation can be next to impossible. GitLab's built-in security functionality includes SAST, DAST, container scanning, and dependency scanning to keep you on top of vulnerabilities and ship secure code. And today, we're improving the experience.

When a vulnerability appears in a report you'll want to take action to either fix it or potentially ignore it if it's a false positive. Now with Interactive Security Reports, you'll have the ability to take action right from the security report to either dismiss a vulnerability or create an issue to remediate it. By enabling users to take swifter action on vulnerabilities, we can help developers ship better, safer code.

Over to you!

We couldn't be more excited to get these changes to you and to hear your feedback. Let us know what you think in the comments below – what are you looking forward to in this release? What can we continue to improve on?

Thanks for being a part of GitLab ❤️

GitLab MVP badge

This month's Most Valuable Person (MVP) is Alexis Reigel

This release’s MVP is Alexis Reigel. Alexis added a stellar contribution in the form of CI runners shared within groups, a highly requested feature. After over a year of perserverance and a ton of collaboration, Alexis’ contribution makes it worlds easier to manage runners for projects in groups.

Thank you, Alexis, for your contribution! We’ve sent Alexis some GitLab swag as a thank you, including a hoodie, socks, and a handmade tanuki.

Key features released in GitLab 10.8

Incremental rollout deployments

When your software application goes through major changes, you may want to deploy the latest version only to a small subset of your fleet to get feedback and to make sure that no problems are present. You can repeat this process in small steps, increasing the percentage of users that will use the new release. Eventually, if no problems are detected, the deployment will replace the previous version. Otherwise, you’re able to revert the changes without creating major problems for users.

With GitLab 10.8, you can now roll out your latest code incrementally to 10, 25, 50, or 100 percent of your pods. This behavior is already supported by Auto DevOps, but should be explicitly enabled by setting the INCREMENTAL_ROLLOUT_ENABLED environment variable.

Incremental rollout deployments

Push Mirroring now open source

Repository mirroring allows you to replicate Git repositories from one location to another. This makes it easier to work with multiple GitLab instances, like mirroring your team’s work to a customer’s private GitLab instance. Push mirroring also makes it easier to move a project to GitLab from elsewhere, without disruption, by keeping the old repository up to date.

Push mirroring, now available in Core, was previously available in GitLab Starter.

Push Mirroring now open source

Interactive feedback in security reports (alpha)

Security reports show which vulnerability may affect your software, but action is needed in order to address these and ensure the security of your product.

With GitLab 10.8, you can create an issue to solve a vulnerability directly from the security report. If it is a false positive, you can also dismiss the entry. This feedback is immediately visible in the report itself.

You can follow the future development of this feature in this epic.

Interactive feedback in security reports (alpha)

Fuzzy file finder in the Web IDE

In the Web IDE, files can now be quickly opened using the fuzzy file finder, making it easier to navigate large projects. The fuzzy file finder can be opened using the Cmd + p/Ctrl + p keyboard shortcut.

Previously, files could only be opened by browsing the file tree.

Fuzzy file finder in the Web IDE

Stage and commit by file in the Web IDE

Changes can now be staged file by file in the Web IDE, allowing you to stage and commit your changes in smaller commits. As you make changes, they are collected in the unstaged changes list. From this list you can select which files to add to the staged changes list, which is the list of changes that will be part of the your next commit.

Stage and commit by file in the Web IDE

Group milestone burndown chart

Many teams use the burndown chart in their projects to track progress over a milestone. But as many of the teams have started to adopt groups and subgroups, folks have also been asking for the same functionality associated with groups.

In this release, we are shipping burndown charts associated with group milestones. Analagous to project milestone burndown charts, a group milestone burndown chart is associated with a group milestone. All issues that are assigned that group milestone will “burndown” throughout that milestone, allowing you to see progress in a visualization. This allows you see the trend of work being completed over time, enabling you to more quickly anticipate any risk of not finishing scoped work and proactively managing that ahead of time.

Group milestone burndown charts allow for both issue count and issue weight in their calculations, just like their project milestone counterparts. Additionally, group milestone burndown charts automatically account for subgroups. If your group has many layers of subgroups with issues assigned to that group milestone, they will all be accounted for in the burndown.

Group milestone burndown chart

GitLab Prometheus service metrics now GA, on by default for new installations

GitLab is often at the heart of an organization’s software delivery lifecycle, so it is important to ensure it is healthy and responsive. We have already added Prometheus metrics to dependencies like Redis and Postgres, and introduced experimental GitLab metrics in 9.3. Since that release, we have instrumented additional portions of our codebase and reduced the impact, and now utilize these metrics to operate GitLab.com.

With these improvements, we are proud to announce that Prometheus monitoring of GitLab is now generally available in 10.8, and will be on by default for all new installations going forward. We have also released a sample Grafana dashboard to easily visualize these metrics.

GitLab Prometheus service metrics now GA, on by default for new installations

Other improvements in GitLab 10.8

Enforce terms of service acceptance

As part of preparing GitLab.com and our users for GDPR, we asked GitLab.com users to review and accept updated Terms of Service. Rather than making this a one-time functionality that we throw away afterward, we decided to build the feature directly into GitLab, so that self-hosted users can use it going forward as well.

When an instance admin has activated the feature in GitLab, users will be required to review a message representing the Terms of Service and accept them before continuing to use GitLab. As long as a user has not yet accepted, GitLab will be blocked via the web, API, and Git traffic.

This message is entirely customizable in the admin settings and is powered by GitLab-flavored Markdown, so you can even link to other pages for users to review detailed information.

The accepts are logged in the database so that you have an audit trail for any compliance purposes your team may need.

Discussions in API

Discussions (threaded comments) appear in the GitLab web interface in a number of places, including issues, merge requests, epics, snippets, and commits. With this release, we have now opened up the API so that you can access and manage these discussions directly via the GitLab API, allowing you even more flexibility in your custom workflows.

Specify variables for manual pipelines

Oftentimes, we find ourselves needing to execute a single CI run with a one-time configuration value to affect behavior that will test a particular use case. For example, we may want to temporarily enable a specific deployment strategy, or to exclude a particular step when building the app.

GitLab 10.8 now offers the ability to specify single-use variables when running a pipeline manually. You don’t have to change the variables for the entire project to affect a single execution, and this makes it very easy to perform non-standard tests with your configuration, keeping it even more flexible.

Specify variables for manual pipelines

System note for adding issue weight

Issue weights allow you to associate a numerical weighting value to issues in GitLab. In particular, teams use it to indicate story points in Agile or Agile-based workflows. With this release, we are including a system note in an issue every time you add or change a weight value. This is useful for team members to track changes in estimated effort, or to simply know when the estimate was first logged.

System note for adding issue weight

GitLab merge requests in Jira Development Panel

We’ve improved the Jira Development Panel integration in this release to include GitLab merge requests. This means that if you use this specific integration feature, you will see GitLab merge requests in the side panel of a linked Jira issue, in addition to GitLab commits and branches from before.

Note that in the Jira UI, these will be called “pull requests.”

GitLab merge requests in Jira Development Panel

Improved display of long commit messages

Writing a good commit message that explains why the change was needed helps you make small, atomic commits and makes it easier for contributors to read the commit log. We’ve improved the formatting of long commit messages so that great commit messages are great to read in GitLab!

Improved display of long commit messages

Project languages API

Using the new Languages API you can now retrieve project language statistics for reporting or research, like understanding which programming languages are being used by your organization or by open source projects hosted on GitLab.com. Thank you Roger for your contribution!

Staging environment policy support for Auto DevOps

Currently, the Auto DevOps feature uses a continuous deployment model by pushing to the production environment automatically every time a new pipeline runs on your master branch. This is very useful, but sometimes the maturity of the application or the importance of having a production environment available requires that a staging environment must be used. Only after checks pass there, a manual deployment to production can be done. This behavior was already supported in the Auto DevOps template, but not enabled by default, and required users to explicitly create a .gitlab-ci.yml file if they wanted to benefit from this feature.

Starting in GitLab 10.8, Auto DevOps templates allow users to enable staging using an environment variable. You can set STAGING_ENABLED for the entire group, a single project or even for a specific run. This automatically turns deployment to production to be a manual action that can be executed at the right time.

Staging environment policy support for Auto DevOps

Geo improvements

  • Geo ships with Git 2.16.3, which significantly improves sync time for repositories with large number of references.
  • A Geo secondary will now initiate a pack after an initial repository clone and regular housekeeping for improved performance.
  • When repository checks are enabled, Geo will periodically run git fsck on each repository on the secondary.
  • Geo Prometheus metrics have been improved to make it easier to tell that repositories that have a mismatched checksum.

Omnibus improvements

  • GitLab 10.8 includes Mattermost 4.9, an open source Slack alternative whose newest release includes muted channels, team icons, plus much more.
  • HTTP compression is now enabled by default, improving responsiveness and reducing bandwidth consumption. To disable, set nginx['gzip_enabled'] = false.
  • GitLab Mattermost 4.9.1 contains fixes for performance regressions and issues with the new permissions system.
  • ruby has been updated to 2.3.7, rubygems has been updated to 2.6.14
  • git has been updated to 2.16.3, openssl has been updated to 1.0.2o
  • libxslt has been updated to 1.1.32, libxml2 has been updated to 2.9.8, rsync has been updated to 3.1.3, curl has been updated to 7.59.0
  • unzip and bzip2 have been patched to address low impact CVE’s
  • Going forward, GitLab packages will check for removed configuration settings before upgrade, requiring users to update the settings first before proceeding
  • Prometheus AlertManager bundled, off by default, to support upcoming proactive notifications
  • The GitLab artwork that is output during reconfigure is now yellow, instead of red

Epic roadmap search and filter bar

The search and filter bar is a very useful and helpful UI used throughout GitLab and is familiar to users. So, we decided to leverage this design to allow for searching and filtering roadmap bars in the roadmap view.

With this release, you can now filter epics by author and label in the roadmap view. Additionally, you can even search by the title and description of epics. This allows users to see epics relevant to them and their teams in the roadmap view, and even bookmark links to save searches.

Epic roadmap search and filter bar

SAST for PHP and Java Gradle

Static Application Security Testing is effective only in the event that your project is using a programming language supported by one of the tools integrated in GitLab. That is why we are increasing their number with each release, adding the most commonly used languages.

In GitLab 10.8, projects written in PHP and Java with Gradle can be automatically checked for security vulnerabilities. No need to specify the language, it will be autodetected at runtime for an easy user experience.

SAST for PHP and Java Gradle

Merge commit in merge request widget

We continually strive to improve the GitLab user experience in small ways that have big impact. This particular feature is a great example. If your project is configured to use merge commits, a merge commit link will now appear in the widget of a merge request after it has been merged. Click on the link to navigate to the merge commit itself.

In many workflows, it’s helpful to navigate directly to the merge commit. For example, some teams extract these merge commits and put them in release branches or tags for testing and or production deploy. With this change, you can now quickly know if a merge request’s work is part of a branch targeted to be deployed.

Merge commit in merge request widget

Issue weight and locked status in CSV export

In this release, we’ve added the issue weight and locked status of issues as part of the CSV export functionality. This gives you even more insight into your issues so that you can perform any type of custom analysis and workflows outside of GitLab.

Epic email notifications

In the last release, we introduced the comment thread to epics. With this release, we’re making collaboration in epics even more in line with the rest of the GitLab experience with email notifications. Just like issues and merge requests, you will receive email notifications (per your personal GitLab settings) in response to activity in an epic. For example, when a team member @-mentions you in an epic description or comment, you will receive an email notification if you have configured your notifications to that epic’s group to be at Participate or higher.

Epic email notifications

Embedded Snippets support

Snippets are useful for starting a conversation about a piece of code, and you can now embed public Snippets on a website. This is perfect for documentation, supplementing a blog post with a code example, or a personal site. Thank you Haseeb for your contribution!

GitLab Runners for groups

GitLab Runners had two ways of configuration: either for the entire instance (shared) or at the project level (specific). Sometimes, however, there is a need to provide a set of Runners to an entire group of projects, but without making them accessible to anyone outside. On GitLab.com, for example, this fits well with the strict relationship between groups and organizations.

Starting in GitLab 10.8, you can connect your own GitLab Runners to a specific group so each of its projects will have CI/CD capabilities without any further configuration. New projects will also benefit from the group’s Runners as soon as they are created. Thank you Alexis for your contribution!

GitLab Runners for groups

Project templates now work with Auto DevOps

GitLab provides an easy way to get started with language-specific projects by using templates. Leveraging project templates allows you to quickly get a new application up and running, and then customize it to better fit your specific needs.

GitLab 10.8 now includes an improved version of the Rails, Spring, and Express templates to make full use of Auto DevOps features when creating new projects. You can go from idea to production in mere minutes by take advantage of these enhanced templates.

Project templates now work with Auto DevOps

GitLab Runner 10.8

We’re also releasing GitLab Runner 10.8 today! GitLab Runner is the open source project that is used to run your CI/CD jobs and send the results back to GitLab.

Most interesting changes:

List of all changes can be found in GitLab Runner’s CHANGELOG.

Deprecations

API v3

API v4 has been the preferred version of the GitLab API since 9.0. With GitLab 11.0, API v3 will be removed and no longer supported.

Removal date: GitLab 11.0.

Mattermost configuration changes

With the release of GitLab 11.0, Mattermost configuration is being simplifed. The core settings necessary to run Mattermost and integrate with GitLab will continue to be set gitlab.rb, however the rest must now be configured in the Mattermost System Console.

Learn more about configuring Mattermost in GitLab 11.0.

Removal date: GitLab 11.0.

Support for DSA SSH keys

Due to published weakness in the ssh-dss algorithm, we’ll begin winding down support for DSA SSH keys. In the iteration planned for 11.0, we plan to continue allowing existing DSA keys – but prevent new keys from being added to GitLab.com. We’ll prevent this by default for self-hosted instances, but allow instance admins to override this setting.

In a future release, we’ll reject DSA keys for all GitLab instances.

Removal date: GitLab 11.0.

Debian 7 Wheezy Support

GitLab 11.0 will be the last release with support for Debian 7 Wheezy.

Debian Wheezy will be officially end of life at the end of May 2018.

Removal date: GitLab 11.0.

Dynamically generated milestone pages

GitLab currently offers both project milestones and group milestones. In particular, you can assign issues within projects of that group (and even within subgroups).

There is an existing feature in GitLab that allows you to pull in multiple project milestones with the same name, together in one page. In the past, this was created to solve some of the use cases of how group milestones work now. But since we now have group milestones as a first-class, native object, we no longer need this dynamically generated page. We will thus deprecate these dynamically generated milestone pages.

Removal date: GitLab 11.2

Upgrade barometer

To upgrade to GitLab 10.8 from the latest 10.7 version, no downtime is required. To upgrade without downtime, please consult the documentation on downtimeless upgrades.

For this release we have migrations, post-deploy migrations, and to help with the larger migrations we have introduced background migrations.

GitLab.com migrations took approximately 10 minutes and post-deploy migrations amounted for a total of around two minutes. Background migrations on the other hand are sidekiq jobs that will run synchronously, for this release these migrations took less than a day to complete, no side effects were expected nor present; these target older pipeline builds so newer executed pipelines are not affected.

GitLab Geo users, please consult the documentation on upgrading Geo.

Changelog

Please check out the changelog to see all the named changes:

Installing

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

Updating

Check out our update page.

GitLab Subscription Plans

GitLab is available in self-managed and cloud SaaS options.

Self-managed: Deploy on-premises or on your favorite cloud platform.

  • Core: For small teams, personal projects, or GitLab trials with unlimited time.
  • Starter: For co-located teams with few projects who need professional support.
  • Premium: For distributed teams who need advanced features, high availability, and 24/7 support.
  • Ultimate: For enterprises that want to align strategy and execution with enhanced security and compliance.

Cloud SaaS - GitLab.com: hosted, managed, and administered by GitLab with free and paid subscriptions for individuals and teams.

  • Free: Unlimited private repositories and unlimited collaborators on a project. Private projects get access to Free features, public projects get access to Gold features.
  • Bronze: For teams that need access to more advanced workflow features.
  • Silver: For teams that need more robust DevOps capabilities, compliance and faster support.
  • Gold: Great with many CI/CD jobs. Every public project get the features of Gold for free irrespective of their plan.

Cover image licensed under Unsplash free license

Install GitLab in 2 minutes

With Ubuntu, Debian, CentOS, openSUSE, and Raspbian packages or from source

Install GitLab Now

Try GitLab Enterprise Edition risk-free for 30 days.

No credit card required. Have questions? Contact us.