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.
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.
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.
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.
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 ❤️
Key improvements 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.
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.
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.
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.
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.
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.
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.
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-managed 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.14git has been updated to 2.16.3, openssl has been updated to 1.0.2olibxslt 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.0unzip 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:
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:
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.
Planned 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.
Planned 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-managed instances, but allow instance admins to override this setting.
In a future release, we’ll reject DSA keys for all GitLab instances.
Planned 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.
Planned 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.
Planned removal date:
GitLab 11.2
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
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.
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