GitLab.org/GitLab: Release v10.3.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 10.3
Released: 2020-04-03
License: MIT
Release Assets:
#### [Ultimate](https://about.gitlab.com/pricing/ultimate/)
[Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)
> Running secure application code in production is critical;
> vulnerabilities can lead to everything from denial of service to leaked
> user information. Running security checks on a regular basis helps
> protect you from known vulnerabilities, even if they are affecting
> libraries you import in your projects.
>
> With GitLab 10.3, Static Application Security Testing (SAST) scans the
> code (also known as static analysis) for known security issues that
> could be exploited by malicious users, like unpatched external
> dependencies or cross-site scripting vulnerabilities. It automatically
> recognizes the most common languages (Ruby, JavaScript, and Python are
> currently supported), and a summary shows up directly in Merge Requests
> so your team is aware of potential problems before merging code into
> master and deploying it to production. Static Application Security
> Testing is also now [part of Auto
> DevOps](https://docs.gitlab.com/ee/topics/autodevops/#auto-sast) to
> provide security by default.
[Navigate to epic from issue](https://docs.gitlab.com/ee/user/group/epics/)
> Since issues can only belong to one epic, when looking at an issue it's useful to know if
> it already belongs to an epic. The containing epic of an issue now appears in the issue
> sidebar as a link, allowing you to quickly navigate to it.
[Attach images to epics](https://docs.gitlab.com/ee/user/group/epics/)
> You can now attach images (or any file) to an epic, via the epic
> description, just like in an issue description (and other Markdown
> boxes in GitLab). This allows you to be even more descriptive in
> documenting epics, such as by including inline wireframes and mockups.
[Render links to epics in GitLab Flavored Markdown (GFM)](https://docs.gitlab.com/ee/user/markdown.html#special-gitlab-references)
> Links to epics in GitLab Flavored Markdown (GFM) textboxes will now be
> rendered similar to issues, merge requests, and other objects in GitLab.
> The group path is shown followed by `&`, and then the epic ID. A helpful
> tooltip shows the epic title. This allows you to paste a link to an epic
> in a textbox, and GitLab will render it more compactly and in a more readable fashion.
> You can also directly enter the shorthand for the epic reference in the GFM field, such as
> `gitlab-org&23`, and GitLab will turn that into link.
[Browser Performance Testing](https://docs.gitlab.com/ee/user/project/merge_requests/browser_performance_testing.html)
> GitLab offers a great way to monitor the performance of your production
> application, but it's also critical to ensure that new code doesn't
> introduce performance regressions. For example, a developer may
> incorporate a new image from design, but forget to compress it; or a new
> JavaScript library may be added to ``, slowing down page load.
> Catching these regressions with only a manual review can be challenging.
>
> To help address this, we are introducing an easy way to analyze the
> performance impact of a merge request for web apps. Browser Performance
> Testing runs a headless browser to simulate visiting one or more pages
> of your application and analyzes them. A summary of performance changes
> is provided on the merge request so you're aware of the performance impact
> *before* merging into `master`.
[Multiple Kubernetes clusters per project (Beta)](https://docs.gitlab.com/ee/user/project/clusters/#multiple-kubernetes-clusters)
> GitLab can easily deploy your application to different environments
> within a Kubernetes cluster. We commonly see Development, Staging, and
> Production, and Review Apps all published in the same way. Up until now,
> they all lived in the same cluster, but you may have the need to keep
> data and access separated, for example if regulations require you to
> store production data in a different physical location.
>
> With GitLab 10.3, you can configure multiple clusters for each project,
> each linked to a specific environment, so the right cluster is
> automatically used by CI/CD pipelines to publish your application.
[Only mirror protected branches](https://docs.gitlab.com/ee/user/project/repository/repository_mirroring.html#push-only-protected-branches)
> Pull and push mirroring, when enabled for a repository, will
> automatically mirror to and from the configured target Git repository.
> But this fails if any pushes contain altered Git history, such as by
> rebasing. It's normally not a good idea to rebase certain key branches,
> like `master`, but it's more common for feature branches.
>
> To prevent rewritten history from a feature branch causing mirroring to
> fail, mirroring can now be limited to only protected branches.
[Trigger pull mirroring via API](https://docs.gitlab.com/ee/user/project/repository/repository_mirroring.html#trigger-update-using-api)
> Pull mirroring, when enabled for a repository, automatically mirrors
> changes from the configured upstream Git repository to your repository.
> Changes are mirrored regularly when they are detected by polling.
>
> A new API has been added to trigger changes to be pulled immediately.
> When used with a push event webhook from the upstream repository, pull
> mirroring can happen within seconds.
[Immediate push mirroring](https://docs.gitlab.com/ee/user/project/repository/repository_mirroring.html#pushing-to-a-remote-repository)
> Push mirroring, when enabled for a repository, will automatically
> push changes to the configured downstream Git repository.
>
> The rate limit has been updated to push changes immediately, but is
> limited to one push every five minutes. If mirroring is limited to
> protected branches, the rate limit is decreased to one push every
> minute.
[Restrict Repository Mirroring to admins](https://docs.gitlab.com/ee/user/project/repository/repository_mirroring.html) (self-managed only)
> Push and pull mirroring, when enabled for a repository, will
> automatically mirror to or from the configured target Git repository.
>
> In GitLab 10.3 push mirroring can be restricted to admins. Now admins
> can limit access to push and pull mirroring to only admin users, to
> prevent repositories being replicated to or from a GitLab instance.
[Improved Geo nodes dashboard](https://docs.gitlab.com/ee/administration/geo/replication/configuration.html#step-6-verify-proper-functioning-of-the-secondary-node) (self-managed only)
> Managing and monitoring of Geo nodes is improved by separating the
> monitoring interface from the process of adding and editing a Geo node.
[Simplified PostgreSQL HA configuration](https://docs.gitlab.com/omnibus/roles/#postgres-roles) (self-managed only)
> In GitLab 10.2 [Postgres HA became generally available](https://about.gitlab.com/releases/2017/11/22/gitlab-10-2-released/#postgres-ha-is-now-generally-available), making it easy to set up a production Postgres database cluster using our Omnibus package.
>
> Now we are making it even easier with the introduction of [new Postgres roles](https://docs.gitlab.com/omnibus/roles/#postgres-roles). These roles significantly reduce the configuration required to set up standalone database nodes, by automatically turning off all other features and components.
[Handling oudated replicas with database load balancing](https://docs.gitlab.com/ee/administration/database_load_balancing.html) (self-managed only)
> The database load balancer included in GitLab Enterprise Edition has
> been improved so it can handle replicas that are lagging behind too
> much. This has been combined with adjustments to the replica status
> checks to reduce the number of queries necessary to check if a replica
> is available.
>
> These changes allow the database load balancer to stop sending read-only
> queries to replicas when those replicas are lagging behind with
> replicating data from a primary.
>
> For more information check the merge request on
> [how we handled outdated replicas in the DB load balancer](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/3526).
[Merge Request Commit Discussions](https://docs.gitlab.com/ee/user/discussions/#commit-discussions-in-the-context-of-a-merge-request)
> GitLab works great for workflows where teams collaborate and comment on
> each new version of a merge request.
>
> But some teams work at the individual commit level; they want to have
> conversations about every single commit, even within a push containing
> multiple commits. This was not possible previously.
>
> Today, we are shipping commit-based workflows in merge requests. Simply
> navigate to the commits tab of a merge request and click on a commit to
> bring you to the changes tab, with a new interface that allows you to
> have a resolvable discussion about a particular commit. That discussion
> is also shown in the discussion tab itself, along with other
> conversations. This feature works alongside the existing workflow,
> giving your team flexibility to select whichever flow works best. View [a
> short demo](https://about.gitlab.com/blog/2018/01/04/comment-on-commits-feature-tutorial/)
> of the new workflow.
[Customize branch name when creating merge request from issue](https://docs.gitlab.com/ee/user/project/issues/issues_functionalities.html#18-new-merge-request)
> You can create a merge request, along with an underlying branch, right
> from an issue in one click. Clicking the create merge request button
> automatically creates a branch name based on the title of your issue.
> But in some cases you don't really want this, especially if your issue
> title is very wordy and you want the branch name to be more succinct. With
> this release, you can now customize the branch name before creation.
> This also works when creating a branch from an issue without an
> associated merge request.
>
> Thank you [blackst0ne](https://gitlab.com/blackst0ne) for the
> contribution!
[Flow charts, sequence diagrams, and Gantt diagrams in GitLab Flavored Markdown (GFM) with Mermaid](https://docs.gitlab.com/ee/user/markdown.html#mermaid)
> You can now create beautiful flow charts, sequence diagrams, and Gantt diagrams in issue / merge requests
> descriptions and comments using GitLab Flavored Markdown (GFM)
> Just follow the simple Mermaid syntax, now supported in GFM.
>
> Thank you [blackst0ne](https://gitlab.com/blackst0ne) for the contribution!
[Automatically run first pipeline when enabling Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/#enabling-auto-devops)
> Previously in GitLab if you enabled Auto DevOps you still had to wait until
> you pushed a commit before your pipelines would populate.
> This was a confusing experience that didn't follow expected behavior.
>
> With GitLab 10.3, a pipeline for your project will be run as soon as you
> enable Auto DevOps in Settings, so you can immediately see results without
> needing to push another commit to your code.
[Strict check on artifacts dependencies](https://docs.gitlab.com/ee/ci/yaml/#when-a-dependent-job-will-fail)
> When dealing with CI/CD pipelines, it is quite common that artifacts are
> created in one job and then used later by another job. Using the
> `dependencies` keyword, you can explicitly list which artifacts from
> previous stages you need. But when jobs are retried some time later,
> those artifacts may no longer exist, for example if they have expired or
> have been manually erased. This could lead to inconsistent states where
> code is expecting to find resources that are not available, creating
> errors that are hard to spot and debug.
>
> In GitLab 10.3, we introduce strict checking on these dependencies. Since
> jobs will fail if their dependencies cannot be found, you'll always be aware
> if something required is missing. This allows you to take proper actions
> to solve the problem, for example running a brand new pipeline from scratch.
[Restricted deletion of CI/CD job logs](https://docs.gitlab.com/ee/user/permissions.html#gitlab-ci-cd-permissions)
> When running a job as part of a CI/CD pipeline, the job log is stored in
> GitLab and is available for further analysis to users that have access
> to the project. It can be also erased in order to avoid information
> leaks or to free up space.
>
> With GitLab 10.3, only Masters and the user that triggered the job are
> authorized to erase the job logs; enforcing a more consistent permission
> model.
[Improved integration with existing clusters (Beta)](https://docs.gitlab.com/ee/user/project/clusters/)
> Until now, configuring a project to use an existing Kubernetes cluster
> (as opposed to creating a new cluster) relied on the service integration
> page in the project settings. This made the flow inconsistent with the
> first-class support for Clusters introduced in GitLab 10.1.
>
> GitLab 10.3 adds the ability to add existing Kubernetes clusters to a
> project, directly from the Clusters page, and deprecates the old service
> integration page.
[Git push and pull on project redirects](https://docs.gitlab.com/ee/user/project/repository/#redirects-when-changing-repository-paths)
> Renaming and moving projects happens all the time. GitLab's web user
> interface has always redirected people from the old location to the new
> location, but the same has not been true for Git actions.
>
> From GitLab 10.3, Git actions will now redirect too! This means that any
> build scripts, automation, or Git clients will continue to work after a
> user or group rename, making any transition a lot smoother.
>
> Please note, to avoid pulling from or pushing to an entirely incorrect
> repository, the old path will be reserved.
[Show project member role on list of projects](https://docs.gitlab.com/ee/user/permissions.html)
> When working with multiple projects, sometimes it's difficult to remember what
> permissions you have for each project. This can lead to frustrating situations and
> not knowing why certain features aren't available.
>
> Having a quick reference that tells you what permission level you have helps you understand
> your limitations and lets you act within them or request escalated privileges when appropriate.
>
> Now you can see your permission level on the GitLab Project Dashboard next
> to the project name. You no longer have to click into each project and
> dig into the users page to find this info.
[Customize "New Project" page](https://docs.gitlab.com/ee/administration/appearance.html) (self-managed only)
> With thanks to our community contributor, [Markus
> Koller](https://gitlab.com/toupeira), it is now possible for GitLab
> administrators to add your own help text on the "New Project" page.
>
> This is a great way to provide additional instruction to users on how
> projects should be created. As this text supports Markdown, you can link
> to any further pages or documentation to provide additional help.
[User and group additions to Protected Branch API](https://docs.gitlab.com/ee/api/protected_branches.html)
> [Protected
> branches](https://docs.gitlab.com/ee/user/project/repository/branches/protected.html)
> allow you to lock down push or merge access to your repository's
> branches, preventing inadvertent changes entering your code or enforcing
> particular workflows.
>
> One great feature of protected branches is to specify users or groups
> that do have permission to push or merge changes. This is now available
> in the API.
[Update issue weight from Issue Board sidebar](https://docs.gitlab.com/ee/user/project/issue_board.html)
> You are now able to update an issue's weight right from an issue board's
> sidebar, exactly the same as in the issue page itself. This allows you to
> quickly and more fully manage issues when doing planning and tracking
> from within a board.
[Sort milestones on group milestone list](https://docs.gitlab.com/ee/user/project/milestones/#creating-a-group-milestone)
> You are now able to sort milestones on the group milestone list page,
> similar to the project milestones list page. We introduced group
> milestones a few releases ago and are working to bring features from
> project milestones to group milestones.
>
> Thank you [George Andrinopoulos](https://gitlab.com/geoandri) for the contribution!
[Redesigned merge request diff file navigation](https://docs.gitlab.com/ee/user/project/merge_requests/#merge-request-diff-file-navigation)
> The merge request diff file navigation has been redesigned to more
> clearly show the file name in its own line. The file path is also now
> truncated at the start if it is too long.
[Smarter autocomplete for label quick action](https://docs.gitlab.com/ee/user/project/quick_actions.html)
> When using quick actions to add or remove labels to an issue or merge
> request, the autocomplete dropdown is extremely helpful to quickly find
> what you are looking for. With the latest change, autocomplete is even
> smarter so that when adding a label, the dropdown _doesn't_ show labels
> that are already added. And when removing a label, the dropdown _only_
> shows labels that are already added.
>
> Thank you [blackst0ne](https://gitlab.com/blackst0ne) for the
> contribution!
[Create merge request through email](https://docs.gitlab.com/ee/user/project/merge_requests/#create-new-merge-requests-by-email)
> Some people prefer doing development as much as possible using their desktop
> tools, reserving their use of the GitLab web interface for tasks which are
> absolutely necessary there.
>
> With today's release, you can now create merge requests through email, expanding
> the breadth of developer-focused features you can use with your existing tools.
> Send an email to GitLab, specifying the source branch name in the email subject
> line, and GitLab will automatically create the merge request for you. Find the
> special (and unique-to-you) email address for a given project by clicking the link
> at the bottom of the project merge requests page. It doesn't change (unless you refresh it).
> So you can safely save it in your email client.
>
> For developers who do development, Git, and email all inside a terminal, you can now
> do everything up to creating a merge request all without leaving that terminal.
[Total issue time spent in milestone](https://docs.gitlab.com/ee/user/project/milestones/#milestone-sidebar)
> Many teams track how much time is spent working individually on issues.
> With this latest change, you can now see how much time is spent on all
> of the issues in a single milestone, summed up together, in the sidebar
> of the milestone page.
>
> Thank you [George Andrinopoulos](https://gitlab.com/geoandri) for the
> contribution!
[GitLab Mattermost 4.4.5](https://docs.gitlab.com/omnibus/gitlab-mattermost/) (self-managed only)
> GitLab 10.3 includes [Mattermost 4.4.5](https://about.mattermost.com/blog/mattermost-4-4/), an [open source Slack alternative](https://about.mattermost.com/), whose newest release includes the beta release of plugin support, plus much more.
[GitLab Runner 10.3](https://docs.gitlab.com/runner/)
> We're also releasing GitLab Runner 10.3 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 Kubernetes executor connection with service account, bearer token can also be overwritten](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/744) – thank you [David Schile](https://gitlab.com/bajacondor) from Nordstorm's CI team for the contribution!
> * [Stop Docker Machine before removing it](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/718)
> * [Add `--checkout --force` options to `git submodule update --init`](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/704)
> * [Fix trailing `[Omnibus improvements](https://docs.gitlab.com/omnibus/README.html) (self-managed only)
> * Additional warnings have been added for deprecated settings, and they now appear in red.
> * gpgme 2.1.15 is now packaged with Omnibus GitLab, making it easier to use [signed commits](https://docs.gitlab.com/ee/user/project/repository/signed_commits/gpg.html).
> * Git has been updated to 2.14.3
> * Docker Registry has been updated to 2.6.2
> * Redis has been updated to 3.2.11
[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.3)
> We are continuing to make great strides in improving
> the performance of GitLab in every release.
> [We're committed](/handbook/product/gitlab-the-product/#performance) to not only
> making individual instances of GitLab even faster,
> but also to greatly improving the performance of GitLab.com,
> an instance that has over one million users!
>
> In GitLab 10.3 we are shipping 24 performance improvements for merge
> requests, CI/CD, Prometheus, frontend, and a lot more! Some of the
> noteworthy improvements include:
>
> * [Performance of loading large / many Wiki pages has been improved](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15276)
> * [Search performance has been improved by adjusting search behaviour based on the number of characters of the search query](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15592)
> * [The number of timestamp updates for issues and merge requests has been reduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15682)
> * [Redundant import status checks have been removed](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15752)
> * [Object allocation tracking has been removed to remove the negative impact this had on performance](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15834)
> * [Stop sending milestone and labels for Projects::MergeRequestsController#show.json requests](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15847)