9.3

GitLab 9.3 Release

GitLab 9.3 released with Code Quality and Multi-Project Pipeline Graphs

GitLab 9.3 Released with Code Quality, Multi-Project Pipeline Graphs, Conversational Development Index, Improved Internationalization, Snippet Descriptions, and much more!

GitLab is an integrated product for the entire software development lifecycle. With each monthly release, we work to bring more aspects of social coding, continuous integration, release automation, and monitoring into a single tool. With GitLab 9.3, we're helping teams improve code quality, reduce cycle time and make complex projects easier to manage.

GitLab 9.3 introduces Code Quality reports displayed directly in the Merge Request widget! Code Quality gives you immediate insight into how a change will affect the health of your code and project. This will reduce your review time and allow you to catch mistakes before merging a change.

Modern production-level software is often composed of many different projects, especially those adopting micro-services architecture. Therefore, understanding the relationships between these projects is crucial. With GitLab 9.3, you can see how upstream and downstream project pipelines are linked together with Multi-Project Pipelines Graphs.

In addition, this release gives you an extremely powerful way to compare your usage of each facet of GitLab with other people, using the Conversational Development Index. The ConvDev Index gives you a quick overview of how you perform in going from Idea to Production and where you have the opportunity to optimise.

To give you a quick idea of the power of GitLab, we've recorded a short demo that highlights some of GitLab's new features. Enjoy the ability to have your entire development workflow in one single platform!

Join us for an upcoming event

GitLab MVP badge

MVP This month's Most Valuable Person (MVP) is awarded to Huang Tao

Huang was incredible in supporting our efforts to make internationalization a first-class citizen of GitLab by leading the community efforts to source and implement translations in new languages. Thank you Huang!

9.3 Key improvements released in GitLab 9.3

GitLab Code Quality

GitLab Code Quality

It’s hard to overstate the importance of proper code review. When reviewing changes, you will need to pay attention to code quality, implementation, formatting, etc. Even with amazing reviewers, consistency is impossible without the ability to measure quality.

To speed up code review and to give you the ability to check, measure and improve code quality, we’ve built GitLab Code Quality. Code Quality will check your code and report changes in quality directly in merge requests. This means your code reviews are faster and you guarantee that you’re not accumulating technical debt. Of course, if the quality of your code goes down, we will show you exactly where, so you can improve your code before merging.

GitLab Code Quality

Multi-Project Pipeline Graphs

Multi-Project Pipeline Graphs

Larger projects, especially those adopting microservices architecture, often have a set of interdependent components that form the complete product. It may be difficult for a developer to follow all the links between interconnected projects and understand why a specific pipeline has run, or if another project has been rebuild because of a commit in the current one.

GitLab 9.3 is now able to display links for upstream and downstream projects directly on the pipeline graph, so developers can check the overall status of the entire chain in one single view. From now on, connections between different projects are clear and simple to follow, and they’re automatically created with no extra effort when using $CI_JOB_TOKEN variable with triggers.

Multi-Project Pipeline Graphs

Conversational Development Index

Conversational Development Index

Last September we announced Conversational Development (ConvDev), an evolution of software methodology that accelerates your development lifecycle, from idea to production. By fully using GitLab’s integrated platform of features, you can reduce that end-to-end cycle time.

With GitLab 9.3, we are shipping the ConvDev Index to measure that feature usage. The ConvDev Index even compares your usage with other top-performers using GitLab, helping you identify which parts of your workflow you can further improve.

In this first iteration, the metrics are only available to GitLab system administrators, aggregating data across your entire GitLab instance amongst active users.

Conversational Development Index

Protected Variables for Enhanced Pipelines Security

Protected Variables for Enhanced Pipelines Security

Secret variables are very useful if you want to avoid external people to access private information for your project, but users that are able to modify the project could still get access to it. This might cause unintended people to affect production environments even if they have no write permissions to the master branch.

In GitLab 9.3, Protected Variables introduce an additional layer of security to your sensitive information, such as deploy credentials. You can now mark a variable as “protected” when defining it in Settings -> CI/CD Pipelines, making it available only to jobs running on protected branches, therefore only authorized users can get access to it.

Protected Variables for Enhanced Pipelines Security

Centralized Audit Log

Centralized Audit Log

Many companies have the need for audit and compliance across the entire development cycle. In GitLab 9.3 any system administrator has access to an improved, centralized Audit Log that includes all audit events from Groups, Projects, and user actions.

The centralized Audit Log also includes the ability to filter events by type and name, so you can easily track down events by group, project or user.

Centralized Audit Log

Repository Settings Made Simple

Repository Settings Made Simple

Over time, the number of settings in GitLab has expanded as we’ve extended functionality and configuration options for projects and groups.

In GitLab 9.3 we will start to simplify the settings pages by making the Repository Settings page a lot more readable.

Settings will be better grouped and allow people to see an overview of all the settings available for a certain section.

Repository Settings Made Simple

9.3 Other improvements in GitLab 9.3

JIRA Settings Improvements

JIRA Settings Improvements

For JIRA users, we improved the JIRA integration settings in this release, making it easier to set up and test your connection from your GitLab project to a JIRA server instance. There is now also a separate Web URL field and a JIRA API URL. This is useful for when your JIRA instance is configured such that the JIRA REST API and the JIRA issues location do not share the same URL.

JIRA Settings Improvements

Group Label Permissions

Group Label Permissions

The Reporter, Developer, Master, and Owner roles can now create and edit group labels. Previously, only Master and Owner roles could do this. This brings parity with permissions of project labels.

Edit Issue Description Inline, Without Losing Context

Edit Issue Description Inline, Without Losing Context

The issue description serves as the single source of truth when teams collaborate on work and ideas are rapidly flowing in the issue comment thread. With this release, you now edit the issue description by clicking Edit, as before. But you remain on the same page, instead of going to a separate web form. Just make your changes inline, and click Save changes to persist the updates without refreshing the page. While editing, you can also easily scroll down on the page to review comments and even copy GFM text and paste it back into the description.

Edit Issue Description Inline, Without Losing Context

Issue Board Usability Improvements

Issue Board Usability Improvements

We recognize that teams use Issue Boards in a variety of ways. To make it usable for even more teams, we now have collapsible Backlog and Closed columns. We’ve also tweaked adding issues in a board. When you click the plus sign +` to add an issue to a list, it now appears at the top of the list automatically, which is really helpful for long lists.

Issue Board Usability Improvements

Internationalization of Project Home & Repository Files Pages

Internationalization of Project Home & Repository Files Pages

In GitLab 9.2 we started the process of internationalization with the Cycle Analytics page in German and Spanish. In GitLab 9.3 we are extending this to more frequently used pages such as the Project Home and Repository Files pages.

The GitLab community are already starting to add more languages such as Chinese, Bulgarian, and Brazilian Portuguese. You can follow the progress and take a look at the contributing guidelines to get involved.

Internationalization of Project Home & Repository Files Pages

Access private Container Registry images

Access private Container Registry images

When you deploy your docker-based project, you need to pull your image every time the deployment environment needs to start them. Since the integrated GitLab Container Registry is the natural choice to store your containers, in GitLab 9.3 you can use it to distribute them too!

By creating a personal access token with the brand new read_registry scope, you have a persistent deploy token that could be used by external services, like Kubernetes, to access your images every time it’s needed, without giving your full credentials or using a dummy user for this task.

Access private Container Registry images

During merge request code review, we are constantly making code changes and commenting on those changes. It is often difficult to keep track. In particular, suppose we start commenting on a particular code line, and there are subsequent changes to that line. You may end up discussing something that has already changed.

With this release, we added a system note to indicate that a line has already changed, so that when you are participating in comments with respect to a particular line, you know that it’s already been changed, and can even see the change by clicking through.

System Note with Link to Change in Outdated Diff Discussion

Auto-cancel Redundant Pipelines Now Set to On for All Projects

Auto-cancel Redundant Pipelines Now Set to On for All Projects

In order to benefit from the automatic cancellation of redundant pipelines and save a lot of time during your development process, GitLab 9.3 sets this behavior to on for all existing and new projects.

If you really do want to disable it and keep redundant pipelines running, you can tune the parameter to reflect your needs.

Upcoming Nginx Upgrade

Upcoming Nginx Upgrade

As part of the upcoming GitLab 9.4 release, we will be upgrading the version of nginx included in our Omnibus packages to the new stable release, 1.12. Version 1.12 includes a number of improvements over the previous stable release, including the ability to filter the log output.

This will be a transparent upgrade for users, however if you have added your own customizations to the nginx configuration, please ensure they continue to work with version 1.12.

Debian 9 Support

Debian 9 Support

Support is available for the recent release of Debian 9. Official Omnibus packages for GitLab 9.3 can be downloaded from our installation page.

GitLab Mattermost 3.10

GitLab Mattermost 3.10

GitLab 9.3 includes Mattermost 3.10, an open source Slack-alternative with new support for Turkish language, new keyboard shortcuts, and much more.

Omnibus Improvements

Omnibus Improvements

The bundled Git and PostgreSQL packages have been updated. Git is now v2.13.0 and Postgres is v9.6.3.

Snippet Descriptions

Snippet Descriptions

Snippets now have descriptions. This follows personal snippet comments, which were added in the previous release. Snippets are a great tool for quick and informal collaboration around code ideas. We’re now bringing the power of issues and merge request collaboration to snippets too.

Snippet Descriptions

Performance Improvements

Performance Improvements

We are continuing to make great strides improving the performance of GitLab in every release. Not only will this make individual instances of GitLab even faster, but will also greatly improve the performance of GitLab.com, an instance that has over 1 million users!

In GitLab 9.3 we are continuing to make listing projects a lot faster and improving performance overall server performance by making changes to how we mirror repositories. Syntax highlighting on files will also be cached to improve overall performance and make viewing commits noticeably faster.

There are numerous other performance enhancements in GitLab 9.3 that should not only make GitLab feel faster, but reduce overall impact on server infrastructure.

Bulk-Editing Issues Re-Design

Bulk-Editing Issues Re-Design

We’ve made bulk editing issues even simpler and more intuitive in this latest release. We’ve leveraged the sidebar paradigm that already pervades GitLab. So users will feel right at home using a transient sidebar when updating multiple issues at once.

Bulk-Editing Issues Re-Design

Search/Filter Bar Improvements

Search/Filter Bar Improvements

We continue to make incremental improvements to the search/filter bar. You can now view user avatars.

Also, by clicking on a filter, it activates the dropdown, allowing you to change filters quickly.

Search/Filter Bar Improvements

Improvements to GitLab Subgroups

Improvements to GitLab Subgroups

In GitLab 9.0 we introduced Subgroups, allowing for more flexibility and management of groups and projects.

We are continuing to improve this functionality in every release and in GitLab 9.3 we are making the discoverability and navigation of Subgroups a lot better. On the Groups page you can now see an expandable tree view of all subgroups and projects rather than having to navigate and explore them one page load at a time.

Improvements to GitLab Subgroups

Enhanced View for Repository Files

Enhanced View for Repository Files

When viewing files in your repository, some extra information is now automatically extracted and reported in the same page.

Starting with GitLab 9.3, you can see if your .gitlab-ci.yml or .gitlab/route-map.yml are valid or not, and which are the parsing errors. LICENSE files are also analyzed, and the information about the specific license is easily accessible with a link for further details about it. Dependency management systems are also exposed to make it clear what the projects rely on.

Enhanced View for Repository Files

Autolinking Package Names

Autolinking Package Names

Ah, packages, those little gems (hah!) of wisdom wrapped up and ready for re-use. GitLab will now automatically detect and link packages in the file view, saving you valuable clicks every day. Neat, huh?

This functionality will work for the following packages and languages:

  • *.gemspec (Ruby)
  • package.json (Node.js)
  • composer.json (PHP)
  • Podfile (Objective-C)
  • *.podspec (Objective-C)
  • *.podspec.json (Objective-C)
  • Cartfile (Objective-C)
  • Godeps.json (Go)
  • requirements.txt (Python)
Autolinking Package Names

API Support for Pipeline Schedules

API Support for Pipeline Schedules

In GitLab 9.2 we released Pipeline Schedules that can be configured and managed using the UI. Today with GitLab 9.3 we’re also releasing calls to create and manage Pipeline Schedules through a set of APIs, in order to allow integration with other tools simple and effective.

Performance Impact of Merge Requests now Quantified

Performance Impact of Merge Requests now Quantified

With GitLab 9.2 we added the ability to see the memory impact of a merge, by adding a sparkline to the Merge Request page. As part of GitLab 9.3 we are taking this further and now quantify the change in average memory usage for the 30 minutes before and after the merge.

It is now easier than ever for developers to be cognizant of the impact they are having on service performance, by getting direct feedback within the tool they already use every day.

Performance Impact of Merge Requests now Quantified

GitLab Runner 9.3

GitLab Runner 9.3

We’re also releasing GitLab Runner 9.3 today!

Most interesting changes:
  • Add GIT_CHECKOUT variable which controls git checkout step (merge request)
  • Add basic support for Volumes in Kubernetes executor (merge request)
  • Add support for cpus option in Docker executor (merge request)
  • Add support for userns option in Docker executor (merge request)
  • Add requests backoff mechanism (merge request)
  • Improve docker machine removal for Docker Machine executor (merge request)

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

Additional GitLab Service Metrics

Additional GitLab Service Metrics

GitLab 9.0 introduced Prometheus monitoring of the GitLab service, providing insight into Redis, PostgreSQL, and system performance.

As part of GitLab 9.3 we have added experimental monitoring of our ruby code base, starting with a handful of metrics like pipeline status and user sign ins. We will continue to instrument additional areas of GitLab in subsequent releases.

Deprecations Deprecations

Dropping Support for Subgroups in MySQL

Dropping Support for Subgroups in MySQL

In 9.0 we released an enhancement to group management by introducing subgroups. Unfortunately, for performance and consistency, we have to drop this feature on GitLab instances running MySQL. Subgroups will no longer be available on MySQL in GitLab 9.3 and the upgrade process will migrate any subgroups to the root of the GitLab server.

While investigating some occurrences of inconsistencies with project membership, we discovered that our approach to implementing subgroups was not efficient enough. While PostgreSQL provides easy workarounds, MySQL unfortunately did not provide any alternatives that did not require vastly changing the way we store the hierarchy of groups.

In order to address the issue, we have removed support from Subgroups in 9.3.

If you are running on MySQL and have created subgroups in your GitLab instance, the upgrade process will convert any subgroups to regular groups.

We continue to support MySQL in general, although some features such as GitLab Geo and Zero-downtime migrations are only available on PostgreSQL.

Planned removal date: June 22nd, 2017.

End of support for the openSUSE 42.1 Omnibus package

End of support for the openSUSE 42.1 Omnibus package

GitLab 9.3 will be the last version to include support for openSUSE 42.1, as it is no longer supported by the community. Starting with GitLab 9.4 (to be released on July 22nd, 2017) we will be offering support for openSUSE version 42.2.

Planned removal date: July 22nd, 2017.

Relative URL changes now require downtime

Relative URL changes now require downtime

Changes to relative URL configuration in Omnibus installations now require a sudo gitlab-ctl restart unicorn after reconfigure to take effect, in order to restart Unicorn. Restarting Unicorn requires downtime.

Planned removal date: June 22nd, 2017.

Removals and breaking changes Removals and breaking changes

The complete list of all removed features can be viewed in the GitLab documentation. To be notified of upcoming breaking changes, subscribe to our Breaking Changes RSS feed.

Upgrade barometer Upgrade barometer

To upgrade to GitLab 9.3, no downtime is required.

However we’re also migrating data for CI jobs and setting the auto-cancel redundant pipelines flag to on for all projects. If you have a significant number of jobs or projects, this could take some time.

If you are using MySQL, you need to grant the database user used by GitLab the TRIGGER permission before upgrading, to prevent issues with migrations:

bash mysql -u root -p -e "GRANT TRIGGER ON \`gitlabhq_production\`.* TO 'git'@'localhost';"

If you use MySQL with replication, or just have MySQL configured with binary logging, you will need to also run the following on all of your MySQL servers:

bash mysql -u root -p -e "SET GLOBAL log_bin_trust_function_creators = 1;"

You can make this setting permanent by adding it to your my.cnf:

log_bin_trust_function_creators=1

Starting with GitLab 9.1.0 it’s possible to upgrade to a newer version of GitLab without having to take your GitLab instance offline. However, for this to work there are the following requirements:

  1. You can only upgrade 1 release at a time. For example, if 9.1.15 is the last release of 9.1 then you can safely upgrade from that version to 9.2.0. However, if you are running 9.1.14 you first need to upgrade to 9.1.15.
  2. You have to use post-deployment migrations.
  3. You are using PostgreSQL. If you are using MySQL you will still need downtime when upgrading.

This applies to major, minor, and patch releases unless stated otherwise in a release post.

A new version of our API was released in GitLab 9.0. While existing calls to API v3 will continue to work until August 2017, we advise you to make any necessary changes to applications that use the v3 API. Read the documentation to learn more.

Changelog Changelog

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

Installing Installing

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

Updating Updating

Check out our update page.

Questions? Questions?

We'd love to hear your thoughts! Visit the GitLab Forum and let us know if you have questions about the release.

GitLab Subscription Plans GitLab Subscription Plans

  • Free

    Free-forever features for individual users

  • Premium

    Enhance team productivity and coordination

  • Ultimate

    Organization wide security, compliance, and planning

Try all GitLab features - free for 30 days

Cover image licensed under CC0

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.

Share your feedback

Take GitLab for a spin

See what your team could do with The DevSecOps Platform.

Get free trial

Have a question? We're here to help.

Talk to an expert
Edit this page View source