10.2

GitLab 10.2 Release

GitLab 10.2 released with Configurable Issue Boards and GitLab Geo General Availability

In this month’s release of GitLab 10.2 we’ve added capabilities to improve planning, reliability, deployment, and so much more!

In this month’s release of GitLab 10.2 we’ve added capabilities to improve planning, reliability, deployment, and so much more.

Plan your work more efficiently

If you’re like me, GitLab issues are water. Essential for life, but huge volumes make you drown.

Getting a view of only the issues you care about for a particular context is crucial to being effective, especially in shared views with teams. Previously, GitLab let you use filters to show a set of issues tied to a particular milestone or label in an issue board, but that was only temporary. Your workflow may have depended on bookmarking a board URL and sharing it with team members as a workaround.

Today, with Configurable Issue Boards you can now save the scope itself (milestone, labels, assignee and weight) to a board, ensuring that every team member sees exactly the same issues.

Fetch faster

Teams are increasingly distributed across larger geographical areas. This is one reason why Git is so popular, Git is distributed by nature – your local Git repository has a copy of every commit, file, and branch in the history of the project. Once the history is downloaded, development is fast!

But if you only have one physical instance, it may be located far away from your distributed teams. The latency caused by this distance can significantly slow fetch operations when large quantities of small files are being downloaded. Today, we're excited to share that GitLab Geo has been released into General Availability. GitLab Geo allows you to run read-only replicas of GitLab, including the GitLab interface, close to your distributed teams.

Stay up and running at scale

GitLab’s single application architecture gives you one unified data store across your issue tracking, source code repository, CI/CD, and monitoring. This unified approach enables additional insights, a better user experience, and greater efficiencies throughout your development organization.

With GitLab at the core of many software engineering groups, it's important however to ensure it is running at peak performance, no matter the time of day. Today we’re proud to announce that PostgreSQL High Availability is now Generally Available, making it easy to set up and run a Postgres cluster for GitLab. With a simple Omnibus-based installation and automatic failover, your developers can work without disruption.

In a nutshell:

  • Single Source of Truth == 😃
  • Single Point of Failure == 😱

Deploy on Kubernetes even faster

With each release, we are making the GitLab Kubernetes experience even better. Last month, we made it easy to spin up new Kubernetes clusters with a few clicks. But once you have a new cluster ready, you need to set up additional services such as an external access controller. In this month’s release, we’re removing that time sink from your schedule by adding one-click installs for Tiller and Ingress. Be on the lookout next month for multi-cluster deployments. We aim to make each iterative step a value-packed ship in and of itself.

See all the features

We’ve shipped a lot of exciting features this month including Commit Author Restriction and Promote Project Milestones to Group Milestones.

Read on to learn more about all of the key features shipped in 10.2!

Join us for an upcoming event

GitLab MVP badge

MVP This month's Most Valuable Person (MVP) is awarded to Travis Miller

Travis has been working to improve GitLab Pages over the past few releases, and with GitLab 10.2 he has contributed to a new Pages API to manage existing domains. This provides the ability to programmatically manage key tasks, like updating an expiring certificate or converting an existing domain to HTTPS.

Thanks Travis for all the hard work! We sent GitLab socks, stickers, a shirt, and a pint glass, which he seems to be making good use of!

Gift for the MVP for this month

10.2 Key improvements released in GitLab 10.2

Configurable Issue Boards

Configurable Issue Boards

Many teams share an issue board to plan and track their work, and so they want the board to reflect the same set of issues seen by anyone on the team. Previously, you were only able to associate a milestone with an issue board. With this release, both project boards and group boards are entirely configurable, so that you can associate a board with a milestone (including the No Milestone choice), multiple labels, an assignee, and a weight, providing many more flexible possibilities for your team.

This configuration is saved with the board itself, so that anyone who visits the board will see that it already has these filters pre-applied. You view and edit this configuration by clicking the View scope or Edit board button (depending on your user permissions).

One-click install for Helm and Ingress on Kubernetes

One-click install for Helm and Ingress on Kubernetes

Starting with GitLab 10.1 you can easily connect your Google account to your projects and create a new Kubernetes cluster directly from the GitLab Cluster page. Then you can use it to host Review Apps and deployment environments.

In GitLab 10.2 we go even further, allowing you to install Helm Tiller and Nginx Ingress with one click into your GKE cluster, reducing the time before you can go live with your applications.

One-click install for Helm and Ingress on Kubernetes

Commit Author Restriction

Commit Author Restriction

GitLab Enterprise Edition Premium provides additional levels of control to your workflow to ensure that strict policies can be enforced within your development environment.

With Commit Author Restriction, it is now possible to ensure that the committer is the same user pushing changes back to the repository. This can prevent unauthorized code entering your codebase or enforce tightly controlled developer workflows.

You can choose to apply this setting to individual repositories, or across the entire GitLab instance to enforce server-wide control.

Used in conjunction with EEP’s ability to reject unsigned commits you can now be in complete control of identity and verification when changes are applied to your repositories in GitLab.

Commit Author Restriction

GitLab Geo is now Generally Available

GitLab Geo is now Generally Available

Many teams who use GitLab are geographically spread out, but your GitLab instance is in a single location. GitLab Geo brings GitLab closer to your team, making fetch operations like cloning repositories faster.

GitLab Geo is now generally available! When configured, GitLab Geo keeps read-only secondaries in sync with your primary GitLab instance. You can use GitLab Geo to access Git, LFS objects, issues, wikis, and CI artifacts from the closest GitLab instance.

Note: while Geo and High Availability are now each individually GA, use of GitLab Geo in combination with High Availability, is considered Beta.

Notable changes shipped with GitLab 10.2:

See full the list of changes for Geo on 10.2

GitLab Geo is now Generally Available

Postgres HA is now Generally Available

Postgres HA is now Generally Available

For many organizations, GitLab is a critical component of their software engineering tool chain, powering not only their code repository but also CI/CD, issue management, and much more. To ensure GitLab is available around the clock it can be deployed in a highly available configuration, providing additional redundancy and scale.

With GitLab 10.2, we are proud to announce that PostgreSQL High Availability is now generally available. As part of GitLab Enterprise Edition Premium, the Omnibus installation package makes setting up a production Postgres database cluster easy.

In the event a database node goes down, the cluster will automatically fail over ensuring your developers flow isn’t interrupted.

Postgres HA is now Generally Available

10.2 Other improvements in GitLab 10.2

Compare production and canary performance

Compare production and canary performance

In GitLab 9.1, we introduced canary deployments to GitLab CI, enabling organizations to easily release software in a more controlled fashion. A new version can be deployed to a small percentage of your app nodes, allowing real-world usage by a subset of users prior to full deployment.

With GitLab 10.2, we have added the ability to track the system metrics of the canary version, allowing easy comparison of the real-world performance between versions. Developers can quickly determine whether a change had a positive or negative impact on performance, and decide whether to proceed with the broader deployment. The best part is that they can do all of this without leaving GitLab!

Compare production and canary performance

Subgroups and projects on the group page

Subgroups and projects on the group page

Subgroups are a great way to organise projects or teams on GitLab. With nearly unlimited nesting of groups, you can create structures to reflect complex repositories, microservices, or even how your internal development teams are structured.

GitLab’s group page has now been given an overhaul to better navigate and explore subgroups and projects. You will now see an expandable tree navigation on the group page, allowing you to quickly find what you’re looking for or discover new projects and groups.

Subgroups and projects on the group page

Personal Access Tokens replacing Private Access Tokens

Personal Access Tokens replacing Private Access Tokens

Personal Access Tokens can be scoped to certain API privileges, thus providing better security when accessing GitLab through the API or third-party applications.

Private Tokens were previously deprecated and have now been completely removed.

All Private Tokens will be migrated to Personal Access Tokens during upgrade, ensuring your existing applications continue to function.

Restrict push repository mirroring to admins

Restrict push repository mirroring to admins

Push mirroring, when enabled for a repository, will automatically mirror it to the configured target Git repository.

Admins can now limit access to push mirroring to only admin users to prevent private projects from being automatically mirrored to another repository that could be external and unsecured.

Improved internationalization

Improved internationalization

As part of our ongoing effort to internationalize GitLab, we have now externalised strings in the Contributors and Tag pages, allowing our translation community to add more languages and strings to GitLab.

If you are interested in contributing to GitLab’s Internationalization efforts, we welcome you to join our translation community.

Project visibility as a CI/CD variable

Project visibility as a CI/CD variable

In GitLab, you can define if you want to create a public project, or if you prefer to keep it private. When dealing with pipelines, sometimes you need this information so you can take different actions.

This information is now available in GitLab 10.2, and reading the CI_PROJECT_VISIBILITY variable you can define, for example, if public access to artifacts and Docker images for the project are allowed. Very useful in case you have a shared template that applies to multiple different projects.

GitLab Mattermost 4.3.2

GitLab Mattermost 4.3.2

GitLab 10.2 includes Mattermost 4.3.2, an open source Slack alternative whose newest release includes a beta support for tablet computers, mobile appenhancements, plus much more. This version includes security updates and an upgrade is recommended.

Performance improvements

Performance improvements

Performance is an important part of GitLab, allowing GitLab to scale to hundreds of thousands of users.

GitLab 10.2 introduces a new GitHub importer that uses Sidekiq to perform its work in parallel, vastly reducing the time spent importing projects from GitHub. In the event of hitting the GitHub rate limit the new importer will suspend work and resume it once the rate limit has been reset, without blocking any Sidekiq workers from performing other work.

For small projects such as https://github.com/yorickpeterse/oga the import time was reduced from 5 minutes to 30-60 seconds, while for larger projects such as https://github.com/kubernetes/kubernetes the import time was reduced from several weeks to 6.5 hours.

For more information on the new GitHub importer, you can check out the CE merge request for these changes.

GitLab 10.2 also includes other 12 performance improvements, with a particular focus on speeding up the load speed of merge requests. We have also made improvements to issue load times, as well as reducing some edge cases which can consume significant server resources.

Improved Audit Events

Improved Audit Events

GitLab Enterprise Edition enhances control and accountability with Audit Events. With GitLab Enterprise Edition Starter (EES) you can view audit events in each project or group. GitLab Enterprise Edition Premium (EEP) includes a centralised audit log where all project events are collated in a single place.

GitLab 10.2 EES & EEP now include additional events for actions taken on projects and groups, including:

  • Project or group created
  • Project or group deleted
  • Project moved, renamed or transferred
  • Group visibility changed
  • User added to group, including permission level of user
  • User permission changed
  • Project added or removed from a group

In GitLab EEP, deleted project and group audit data is now persisted in the server-wide audit log available in the admin area. The IP address of the user performing the action is now also included.

Epics

Epics

With this release, we are launching a very early version of Epics as the first feature of Portfolio Management. Epics are designed to enable you to plan and track your work at the feature level, as opposed to the design and implementation details level of an issue.

Epics are scoped at the group level. After creating an epic with a title, and optionally writing its description, you can then create and link multiple issues with the epic. This is a typical top-down workflow where you plan a high-level feature idea, and then break it down into smaller issues to be implemented. Conversely, you can take a bottom-up approach where you take multiple existing issues that are related and link to them together in a new epic.

For a given epic, any issue belonging to a project in the epic’s group or any of the epic’s subgroups can be linked. An epic also has optional planned start date and planned end date.

Epics are included in Enterprise Edition Ultimate (EEU) and the Gold plan of GitLab.com.

Epics

Promote project milestones to group milestones

Promote project milestones to group milestones

When you’ve outgrown your project, you can easily promote project milestones to group milestones. Simply click the button from the desired project milestone page to promote it to a group milestone. Similar to label promotion, all project milestones with that same title across all projects in the group will be merged together into one group milestone. And all issues and merge requests that previously had any of those project milestones will now automatically have the new group milestone. Project issue boards associated with the previous project milestone are now associated with the promoted group milestone.

Promote project milestones to group milestones

Restore project readme view

Restore project readme view

Your preferred project home page settings allow you to choose the content you want to see on every project’s home page. You can choose between the projects activity, file list and readme, and readme only.

In GitLab 9.0 the readme only option was removed, but has now been restored for those who prefer a minimal project overview.

API for GitLab Pages

API for GitLab Pages

GitLab Pages allow you to publish a static website directly from your project’s pipeline. If you want to make it more professional, you can also define custom domains for your content, and protect them with certificates.

In GitLab 10.2, the management of custom domains for GitLab Pages is available via API calls, so that you can automate adding new domains, getting information for existing ones, and also updating domain information, for example, when your SSL certificate has been renewed.

Omnibus improvements

Omnibus improvements

  • Warnings are now clearly displayed when deprecated configuration settings are used.
  • Support has been added for running separate Redis instances for each persistence class.
  • OpenSSL has been updated to 1.0.2m.
  • libxml2 has been updated to 2.9.6.

GitLab Runner 10.2

GitLab Runner 10.2

We’re also releasing GitLab Runner 10.2 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 Deprecations

GitLab Geo SSH Repository Sync

GitLab Geo SSH Repository Sync

HTTPS repository sync replaces SSH repository sync for GitLab Geo. SSH repository sync will be removed in GitLab 10.3.

Refer to Geo node upgrade documentation to enable HTTPS repository sync.

Planned removal date: December 22nd, 2017

The gitlab Helm chart

The gitlab Helm chart

The gitlab Helm chart is deprecated, and will be replaced by the new cloud native GitLab chart. We are planning for an initial beta release of this new chart in 10.3.

A migration will be required to move from the current deprecated chart, to the new cloud native GitLab chart.

Planned removal date: December 22nd, 2017

Mattermost configuration changes

Mattermost configuration changes

With the release of GitLab 11.0, the number of Mattermost configuration options supported within gitlab.rb will be reduced. We will continue to support the core configuration settings necessary to run Mattermost, and set up the integration with GitLab. Going forward, other configuration settings should be set directly within the Mattermost console, or passed as environment variables.

Presently with two applications attempting to write to the same config file, changes can be lost.

Planned removal date: GitLab 11.0

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 10.2 from the latest 10.1 version, no downtime is required.

To upgrade without downtime, please consult the documentation on downtimeless upgrades.

You can check the status of background migrations by running this command from the Rails console: Sidekiq::Queue.new('background_migration').size.

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

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 Unsplash free license

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