GitLab.org/GitLab: Release v10.7.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 10.7
Released: 2020-04-03
License: MIT
Release Assets:
#### [Ultimate](https://about.gitlab.com/pricing/ultimate/)
[SAST for Go and C/C++](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.7, projects written in Go and C/C++ can be automatically
> checked for security vulnerabilities. No need to specify the language,
> it will be autodetected at runtime for an easy user experience.
[Comments in epics](https://docs.gitlab.com/ee/user/group/epics/)
> With this release, we continue to iterate on our [portfolio management](/direction/#portfolio-management-and-issue-management) feature of Epics.
> Just like with issues, you can now comment on epics, and even start standalone, threaded discussions
> in an epic, just like in issues and merge requests. This allows you to have a conversation
> with your teammates, in an epic directly, at a higher abstraction level, before necessarily
> drilling down in an issue, or even creating one.
>
> This new feature is also supported in [the API](https://docs.gitlab.com/ee/api/discussions.html).
>
> Email notifications and todos are not yet supported in epics, and
> [we are working on them right now](https://gitlab.com/groups/gitlab-org/-/epics/148).
[Dependency Scanning is now an independent feature](https://docs.gitlab.com/ee/user/project/merge_requests/#dependency-scanning)
> Before this release, security checks on external dependencies and libraries
> used by your application were done along with SAST. Even if they are
> related, we think that they should be clearly identified as two separate
> features.
>
> GitLab 10.7 introduces Dependency Scanning as a first-class citizen in
> the Security reports, giving you information about vulnerable libraries
> that should be updated. Results will be available both in the merge request
> and in the pipeline view.
[Custom additional text for all emails](https://docs.gitlab.com/ee/administration/settings/email.html)
> Often, organizations need to add a disclaimer or other related text to all email communications,
> for various operational or compliance requirements.
>
> With this release, we've added this exact feature. GitLab admins can now go into email settings
> and paste in any custom text. That text will then appear at the bottom of all emails sent by GitLab.
[Protected branch unprotect permissions](https://docs.gitlab.com/ee/api/protected_branches.html#protect-repository-branches)
> Protected branches allow push and merge permissions to be restricted by
> branch, like preventing pushes directly to `master`, but any Master
> can bypass these rules by unprotecting the branch. The new unprotect
> restriction can be used to limit which users, groups and roles are
> allowed to unprotect a branch.
>
> Unprotect restrictions can only be set using the API in 10.7, but will
> be [available in the interface](https://gitlab.com/gitlab-org/gitlab-ee/issues/5496)
> in an upcoming release. The admin access level (`60`) may be removed in
> a future release, as we are currently evaluating restrictions to the
> Owner role as an alternative.
[Issue weight in Issue Board card](https://docs.gitlab.com/ee/user/project/issue_board.html)
> You can now view the weight in an issue board card. Previously, when using an issue
> board, to see the weight of an issue, you'd have to click on the issue, and see the
> weight in the sidebar that slides in. With this change, you can now see it in the board
> card itself. This makes it much more easy to quickly scan a board and see the weights
> of issues, giving you a rough sense of the work required in a given list of issues, which
> is helpful in methodologies such as [Agile](/blog/2018/03/05/gitlab-for-agile-software-development/).
[Automatic background verification of Geo replicas](https://docs.gitlab.com/ee/administration/geo/disaster_recovery/background_verification.html) (self-managed only)
> Automatic background verification of Geo replicas will now occur when
> Geo is enabled, to make sure that replicas remain consistent with the
> primary. This is important when using Geo for Disaster Recovery so that
> you can confidently fail over to a secondary, knowing that it is a
> a complete replica of your primary GitLab instance.
>
> GitLab calculates a checksum for each Git repository using `heads` and
> `tags` and verifies that the checksum from the primary matches the
> checksum on each secondary. Verification will be expanded in upcoming
> releases to also include
> [uploads](https://gitlab.com/gitlab-org/gitlab-ee/issues/5591) and
> [`keep-around` refs](https://gitlab.com/gitlab-org/gitlab-ee/issues/5196).
[Group project creation in Starter](https://docs.gitlab.com/ee/user/group/index.html#default-project-creation-level)
> As part of providing additional flexibility around our permission
> model, this will allow group or server admins to set an option that
> will give users with Developer role the ability to create projects.
>
> This feature was previously available in GitLab Premium only.
[Web IDE is now open source](https://docs.gitlab.com/ee/user/project/web_ide/)
> The new Web IDE makes it faster and easier to contribute small fixes
> and resolve merge request feedback by eliminating the need to stash
> changes and switch branches locally.
>
> Using the Web IDE, you can change multiple files, preview Markdown,
> review the changes and commit directly from the browser. The Web IDE
> can be opened when browsing the repository, viewing a file, and
> directly from merge requests so that you can quickly resolve feedback
> or contribute a change while doing a code review. If you open a merge
> request in the Web IDE you can also preview the merge request diff
> before committing, which allows you to review the entire scope of the
> merge request directly in the Web IDE!
>
> Introduced in [GitLab Ultimate 10.4](/releases/2018/01/22/gitlab-10-4-released/#web-ide-editor-beta)
> the Web IDE is now Generally Available (GA).
> We decided to make Web IDE open source, because we believe building something so complex
> and personal as an IDE is only possible together. Plus, this lowers the bar for anyone to
> contribute to their favorite projects.
[Deploy Tokens](https://docs.gitlab.com/ee/user/project/deploy_tokens/)
> Projects may need to provide long lived read-only access to the repository
> or to the Docker images uploaded to the GitLab Container Registry.
> Previously this required using Personal Access Tokens (PAT), but these are
> associated to a specific user account and also share their access.
>
> Deploy Tokens, available in GitLab 10.7, solve this need by providing
> a permanent token that is tied to the specific project. Users
> can define if they want to enable repository or container registry
> access, revoke the token, or set an expiration date.
[Variables support in 'only' and 'except' keywords](https://docs.gitlab.com/ee/ci/variables/#variables-expressions)
> GitLab CI/CD configuration allows you to define conditions to run
> a specific job, using the `only` and `except` keywords. For example, if
> you want a deploy job to run only on the `master` branch.
>
> In GitLab 10.7, we have expanded the syntax to allow variable expressions
> that can be used to define conditional jobs based on the existence
> or value of a specific environment variable. For example, you
> may now define which jobs you want to run just by tuning project
> variables, or you can restrict a job to be scheduled only when the
> `GITLAB_USER_NAME` variable is equal to a specific user.
[Subgroup issues in Group Issue Board](https://docs.gitlab.com/ee/user/project/issue_board.html)
> Group issue boards are a powerful feature to help you manage issues across multiple projects
> across a single group, all in one interface. This is helpful for teams where their work
> might come from multiple different code repositories (and thus GitLab projects).
>
> Prior to this release, the issues in a group issue board only came from immediate child projects
> of that one group. With this release, all issues in projects in all subgroups of the current group also appear
> in that one group board. So if your work is structured in a group and project hierarchy with multiple
> levels reflecting your organization or software product, then this update will extend that
> hierarchy to the group issue board now, giving you more fine-grained control.
[Assigning and filtering by subgroup labels](https://docs.gitlab.com/ee/user/project/labels.html)
> Subgrouping is a powerful feature in GitLab, and we want to extend that functionality to how
> labels are applied in GitLab. With this release, we've made it extremely flexible to apply
> group labels to issues and merge requests at various subgroup levels.
>
> In particular, for a given issue or merge request, you can now apply any group label from that object's
> ancestor groups. This flexibility means that you can create a label at a given group level, and all
> objects in its subgroups will be able to use it.
>
> Since in group issue lists and group merge request lists, you can already see objects belonging to subgroups,
> we've now also made it possible to filter on those lists by group labels that belong to both ancestor
> and descendant groups of the given group, since all those objects can have those labels now. In other words,
> GitLab gives you the power and flexibility to filter by any possible label assignable to those objects.
>
> This filtering capability is also possible in group issue boards for both the filter bar and the board config.
[Project Badges](https://docs.gitlab.com/ee/user/project/badges.html)
> Many projects use badges, such as the
> [GitLab CI/CD](https://docs.gitlab.com/ee/ci/pipelines/settings.html#pipeline-badges)
> and [shields.io](https://shields.io) to reflect status of build and
> code quality. Typically these are added to the project README.
>
> Now badges are a first-class citizen and can be displayed prominently
> below the project description, and can be templated at the group level too.
[GitLab Plugins](https://docs.gitlab.com/ee/administration/file_hooks.html) (self-managed only)
> Being open source means GitLab can always be improved by anyone, but
> not all customers want to upstream their changes, or they may want to
> iterate on them privately first. Up to now, this was only possible by
> running a fork of GitLab, which is hard to keep up to date.
>
> Plugins allow you to respond to
> [GitLab system hooks](https://docs.gitlab.com/ee/system_hooks/system_hooks.html)
> with a script stored on the GitLab server, so you can more easily
> extend GitLab to meet your needs, like automatically configuring custom
> protected branch rules whenever a new project is created.
[HTTP(s) Git protocol always available for CI/CD jobs](https://docs.gitlab.com/ee/administration/settings/visibility_and_access_controls.html)
> With GitLab you can use either SSH or HTTP(s) to access your repositories.
> Sometimes GitLab administrators prefer to block HTTP(s) access for security reasons. For example,
> blocking HTTP(s) prevents users from disclosing their credentials due to an insecure client setup.
> However, blocking HTTP(S) also stopped GitLab Runner from cloning the repository, making CI/CD not work as expected.
>
> Starting with GitLab 10.7, the HTTP(s) protocol will be allowed for clone/fetch requests coming
> from GitLab Runner, even if the same access is explicitly forbidden for users.
> This is not susceptible to the same type of inseucre client vulnerability because
> GitLab Runner always uses OTP tokens that cannot be leveraged to perform attacks.
[Support for JSON Web Token OmniAuth](https://docs.gitlab.com/ee/administration/auth/jwt.html) (self-managed only)
> GitLab uses OmniAuth to allow users to sign into GitLab using popular
> services like Twitter and Google, as well as standard authentication
> solutions like OAuth2. In Gitlab 10.7, support for JSON Web Token (JWT)
> OmniAuth has been added.
>
> JSON Web Token is a compact and self-contained way to securely transmit
> information, and is commonly used for authentication between services.
[Project exports include LFS objects](https://docs.gitlab.com/ee/user/project/settings/import_export.html)
> Project exports allow you to move projects between GitLab instances
> conveniently, including issues, merge requests, labels, wikis and
> uploads. Project exports now include LFS objects so that repositories
> with LFS objects can also be transferred using project exports.
[Runner-specific job timeout](https://docs.gitlab.com/ee/ci/runners/#set-maximum-job-timeout-for-a-runner)
> GitLab currently defines at the project level how long a CI/CD job can run.
> If a job execution exceeds this duration, it is automatically stopped and
> reported as failed.
>
> GitLab 10.7 adds a new timeout setting on the runner itself, which applies
> to all jobs it runs. If this value is less than the project-level setting,
> it will override it. This is particularly helpful for shared runners, in
> order to prevent potential abuse with a project that has set long timeouts.
[Easily get failure reasons for CI/CD jobs](https://docs.gitlab.com/ee/ci/pipelines/index.html#see-why-a-job-failed)
> When a CI/CD job fails, users normally want to check what happened
> and commit a fix to make it succeed as expected. Before this release,
> they had to go into the job details and look at the logs.
>
> To make the debugging easier and faster, GitLab 10.7 introduces the failure
> reason as part of the status badges, make it accessible on mouseover.
[Ubuntu 18.04 Bionic support](/install/#ubuntu) (self-managed only)
> Packages are now available for
> [Ubuntu 18.04 Bionic](https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes),
> which is being released on April 26.
[Improvements to restoring GitLab backups](https://docs.gitlab.com/ee/raketasks/backup_restore.html#restore-for-omnibus-installations) (self-managed only)
> GitLab 10.7 now includes support for restoring to custom nested directories.
> For example if your registry was located at `/var/mypath/gitlab/registry`,
> the restore will now succeed. Previously the task would try to rename the
> existing directory to `[GitLab Pages automatic HTTPS redirect](https://gitlab.com/gitlab-org/gitlab-pages/#https-only-domains)
> GitLab Pages can provide static websites via HTTP or HTTPS protocols.
> HTTPS is normally preferred since it encrypts all the traffic, protecting
> the content while it is transferred over the net.
>
> In the case that both are available, in GitLab 10.7 users can force their projects
> to redirect HTTP requests on the related HTTPS url to improve security and
> guarantee no data is transferred in clear text.
[Automatic renewal of GitLab Let's Encrypt certificate](https://docs.gitlab.com/omnibus/settings/ssl.html#automatic-renewal) (self-managed only)
> In GitLab 10.5, we made it easy to enable HTTPS for your GitLab instance
> by [integrating with Let's Encrypt](/releases/2018/02/22/gitlab-10-5-released/#instant-ssl-with-lets-encrypt-for-gitlab).
>
> With GitLab 10.7, we are making it _even easier_ by no longer requiring
> it to be explicitly enabled as well as automating the renewal process.
> All you need to do to enable HTTPS now is set your `external_url` to
> start with `https://`, and that's it!
[Cloud native GitLab chart available for Core (alpha)](https://docs.gitlab.com/ee/raketasks/backup_restore.html#restore-for-omnibus-installations) (self-managed only)
> With the introduction of [Object Storage support to Core](https://gitlab.com/gitlab-org/gitlab-ce/issues/40781),
> the alpha [cloud native GitLab chart](https://gitlab.com/charts/gitlab)
> can now be used without a license. This chart features a more cloud native
> architecture, with a container for each component of GitLab and no requirement
> for shared storage. These changes will result in increased resilience,
> scalability, and performance of GitLab on Kubernetes.
[Improvements to the environment metrics dashboard](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#monitoring-ci-cd-environments)
> Summary statistics are now available on the environment metrics
> dashboard, displaying the average and maximum values of each series
> within the timespan. For example it is now possible to quickly see
> the average response time for the past eight hours, to understand
> the experience most users are seeing.
>
> Total Pod CPU and Memory consumption are now also displayed,
> providing insight into the resource usage of a particular environment
> in the cluster.
[GitLab Runner 10.7](https://docs.gitlab.com/runner)
> We're also releasing GitLab Runner 10.7 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:
>
> * [Add possibility to specify memory in Docker containers](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/847)
> * [Improve services health check](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/867)
> * [Downgrade Go to 1.8.7](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/869)
> * [Add support for max_job_timeout parameter in registration](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/846)
>
> List of all changes can be found in GitLab Runner's [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/v10.7.0/CHANGELOG.md).
[Omnibus improvements](https://docs.gitlab.com/omnibus/README.html) (self-managed only)
> - GitLab [Mattermost 4.8.1](https://about.mattermost.com/releases/mattermost-4-8/) includes several platform improvements, including an iOS endpoint that enables users to upload files larger than 20MB, plus much more.
> - The default `ssl_ciphers` list for NGINX has been updated, excluding `ECDHE-RSA-DES-CBC3-SHA` and `DES-CBC3-SHA` to address [Sweet32](https://nvd.nist.gov/vuln/detail/CVE-2016-2183).
> - redis_exporter has been updated to 0.17.1.
[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.7)
> Some of the more noteworthy performance improvements in GitLab 10.7
> include:
>
> * [Merge requests will now load faster, with less load](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18383)
> * [MR Changes now partially uses Vue for better UX, faster performance](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests?scope=all&utf8=✓&state=merged&milestone_title=10.7&search=MR+Diffs+Refactor+Part)
> * [Redis usage for merge requests diffs is now lower](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/17746)
> * [The number of personal projects a user has is now cached](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18197)
> * [The API no longer executes a query when the project is invalid](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18322)
> * [Viewing the Atom feed of groups generates fewer queries](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18157)
> * [IDs generated for issues, merge requests, milestones, and epics are now atomic](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18402)