GitLab.org/GitLab: Release v10.8.0-ee

Name: GitLab

Released: 2020-04-03

License: MIT

Release Assets:

![27 new features](https://img.shields.io/static/v1?color=108548&label=new+features&labelColor=525252&message=27&style=for-the-badge "New features added in this release") ![348 total badges](https://img.shields.io/static/v1?color=1F75CB&label=total+features&labelColor=525252&message=348&style=for-the-badge "Total features") #### [Ultimate](https://about.gitlab.com/pricing/ultimate/) ![4 new features](https://img.shields.io/static/v1?color=108548&label=new+features&labelColor=525252&message=4&style=flat-square "New features added to this tier in this release") ![27 total badges](https://img.shields.io/static/v1?color=1F75CB&label=total+features&labelColor=525252&message=27&style=flat-square "Total features in this tier")

[Interactive feedback in security reports (alpha)](https://docs.gitlab.com/ee/user/project/merge_requests/#interacting-with-security-reports)

> 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](https://gitlab.com/groups/gitlab-org/-/epics/202).

[Epic roadmap search and filter bar](https://docs.gitlab.com/ee/user/group/roadmap/)

> 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](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks)

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

[Epic email notifications](https://docs.gitlab.com/ee/user/group/epics/)

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

#### [Premium](https://about.gitlab.com/pricing/premium/) ![6 new features](https://img.shields.io/static/v1?color=108548&label=new+features&labelColor=525252&message=6&style=flat-square "New features added to this tier in this release") ![71 total badges](https://img.shields.io/static/v1?color=1F75CB&label=total+features&labelColor=525252&message=71&style=flat-square "Total features in this tier")

[Incremental rollout deployments](https://docs.gitlab.com/ee/topics/autodevops/index.html#incremental-rollout-to-production)

> 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](https://docs.gitlab.com/ee/topics/autodevops/), but should be explicitly enabled by setting > the `INCREMENTAL_ROLLOUT_ENABLED` environment variable.

[Group milestone burndown chart](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html)

> Many teams use the [burndown chart](https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html) 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.

[System note for adding issue weight](https://docs.gitlab.com/ee/user/project/issues/issue_weight.html)

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

[Issue weight and locked status in CSV export](https://docs.gitlab.com/ee/user/project/issues/csv_export.html)

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

[GitLab merge requests in Jira Development Panel](https://docs.gitlab.com/ee/integration/jira/)

> 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](https://docs.gitlab.com/ee/integration/jira/), > 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."

[Geo improvements](https://docs.gitlab.com/ee/administration/geo/replication/configuration.html)

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

#### Core ![17 new features](https://img.shields.io/static/v1?color=108548&label=new+features&labelColor=525252&message=17&style=flat-square "New features added to this tier in this release") ![250 total badges](https://img.shields.io/static/v1?color=1F75CB&label=total+features&labelColor=525252&message=250&style=flat-square "Total features in this tier")

[Push Mirroring now open source](https://docs.gitlab.com/ee/user/project/repository/repository_mirroring.html#pushing-to-a-remote-repository)

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

[Fuzzy file finder in the Web IDE](https://docs.gitlab.com/ee/user/project/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](https://docs.gitlab.com/ee/user/project/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.

[GitLab Prometheus service metrics now GA, on by default for new installations](https://docs.gitlab.com/ee/administration/monitoring/prometheus/gitlab_metrics.html) (self-managed only)

> 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](/releases/2017/06/22/gitlab-9-3-released/#additional-gitlab-service-metrics). > 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](https://grafana.com/dashboards/5774) to easily visualize these metrics.

[Enforce terms of service acceptance](https://docs.gitlab.com/ee/administration/settings/terms.html) (self-managed only)

> As part of [preparing GitLab.com and our users for GDPR](/blog/2018/05/01/new-gitlab-com-terms-of-service/), > 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](https://docs.gitlab.com/ee/user/markdown.html#gitlab-flavored-markdown-gfm), > 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](https://docs.gitlab.com/ee/api/discussions.html)

> 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](https://docs.gitlab.com/ee/ci/pipelines/index.html)

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

[Merge commit in merge request widget](https://docs.gitlab.com/ee/user/project/merge_requests/)

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

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!

[Embedded Snippets support](https://docs.gitlab.com/ee/user/snippets.html#embedded-snippets)

> 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](https://gitlab.com/haseebeqx) for your contribution!

[Project languages API](https://docs.gitlab.com/ee/api/projects.html#languages)

> 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](https://gitlab.com/rroger) for your contribution!

[GitLab Runners for groups](https://docs.gitlab.com/ee/ci/runners/#group-runners)

> 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](https://gitlab.com/koffeinfrei) for your contribution!

[Staging environment policy support for Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/#deploy-policy-for-staging-and-production-environments)

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

[Project templates now work with Auto DevOps](https://docs.gitlab.com/ee/user/project/working_with_projects.html#project-templates)

> 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](https://docs.gitlab.com/ee/topics/autodevops/) 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](https://docs.gitlab.com/runner)

> 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](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/897) > * [Add new metrics related to jobs requesting and API usage](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/886) > * [Add support for fedora/27 and fedora/28 packages](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/883) > * [Update supported distribution releases](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/887) > * [Change docs license to CC BY-SA 4.0](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/893) > > List of all changes can be found in GitLab Runner's [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/v10.8.0/CHANGELOG.md).

[Omnibus improvements](https://docs.gitlab.com/omnibus/) (self-managed only)

> - GitLab 10.8 includes [Mattermost 4.9](https://about.mattermost.com/releases/mattermost-4-9/), an [open source Slack alternative](https://about.mattermost.com/) whose newest release includes muted channels, team icons, plus much more. > - HTTP compression is [now enabled by default](https://docs.gitlab.com/omnibus/settings/nginx.html#disabling-gzip-compression), improving responsiveness and reducing bandwidth consumption. To disable, set `nginx['gzip_enabled'] = false`. > - GitLab [Mattermost 4.9.1](https://docs.mattermost.com/administration/changelog.html#release-v4-9) 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](https://prometheus.io/docs/alerting/alertmanager/) bundled, off by default, to support upcoming proactive notifications > - The GitLab artwork that is output during `reconfigure` is now yellow, instead of red

[Performance improvements](https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&label_name%5B%5D=performance&milestone_title=10.8)

> Some of the more noteworthy performance improvements in GitLab 10.8 > include: > > * [Diff notes will now load faster](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18657) > * [Calls related to processing notifications are done asynchronously](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18535) > * [Branches are loaded asynchronously when creating a new merge request](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18315)