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

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.

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.

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.”

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!

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.

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.

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.

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.

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.

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!

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.

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:

• Resolve a bug with “OffPeakPeriods” where timezone is set inside of gitlab/gitlab-runner image
• Add new metrics related to jobs requesting and API usage
• Add support for fedora/27 and fedora/28 packages
• Update supported distribution releases
• Change docs license to CC BY-SA 4.0

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

Performance improvements

Some of the more noteworthy performance improvements in GitLab 10.8 include:

• Diff notes will now load faster
• Calls related to processing notifications are done asynchronously
• Branches are loaded asynchronously when creating a new merge request