When working in a feature (source) branch, it’s normal to have it diverge over time from the target branch if you aren’t rebasing frequently. This can result in a situation where both the source and target branch’s pipelines are green and there are no merge conflicts, but the combined output will result in a failed pipeline due to an incompatibility between the changes.
By having your merge request pipeline automatically create a new ref that contains the combined merge result of the source and target branch, then running the pipeline against that ref, we can better ensure that the combined result will be valid.
Please note that if you are using merge request pipelines (in any capacity) and you use private GitLab runners that are version 11.8 or older, you will need to upgrade them to avoid running into the issue described in gitlab-ee#11122. Users of GitLab’s shared Runner fleet are not impacted.
Collaborating on merge requests often involves spotting problems and suggesting a solution. In GitLab 11.6, we introduced support for suggesting a change to a single line.
With 11.10, changes can now be suggested to multiple lines when leaving a comment on a merge request diff, and accepted with a single click, by any user with write permissions to the source branch. This new feature avoids the copy/paste workflow of old.
Scoped Labels enable teams to apply mutually exclusive labels (that share the same scope) on an issue, merge request, or epic, solving the use cases of custom fields and custom workflow states. They are configured simply using a special double colon syntax in the label title.
Suppose you wanted a custom field in issues to track the platform operating system that your features target. And each issue should only target one platform. You would create labels
platform::Linux, and others, as necessary. Applying any one of these labels on a given issue would automatically remove any other existing label that starts with
platform::, as desired.
Suppose you have the labels
workflow::deployed, representing workflow states of your particular team. If an issue already has the label
workflow::development applied, and a developer wanted to advance the issue to
workflow::review, they would simply apply that label, and the
workflow::development label would automatically be removed, as desired. This behavior already exists when you move issues across label lists in an issue board representing your team’s workflow. But now team members who may not be working in an issue board directly, would still nonetheless be able to advance workflow states consistently in issues themselves.
In normal use of the Container Registry with CI pipelines, typically you will end up pushing many iterative revisions to the same tag. Due to the way Docker Distribution is implemented, the default behavior is to preserve all revisions in the system – this ends up consuming a lot of space under this usage pattern. By using the
-m parameter with
registry-garbage-collect, administrators now have an easy way to wipe out these historical revisions and free up valuable storage space.
Users on GitLab.com’s paid plans (Gold, Silver, Bronze) can now purchase additional CI Runner minutes. Previously, users were limited by the minutes quota included in their plan. This improvement enables users to proactively purchase minutes in addition to their free minutes, which reduces the potential for any interruptions in service due to stopped pipelines.
The current price is $8 for 1,000 minutes and there is no cap to how many add-on minutes you can buy. Your add-on minutes will only begin to be used once your monthly quota has been used and whatever add-on minutes are left at the end of the month will roll over. In a future release, we aim to extend this to Free plans as well.
Auto DevOps enables teams to adopt modern DevOps practices with little to no effort. Starting in GitLab 11.10 each job of Auto DevOps is being made available as an independent template. Using the
includes feature of GitLab CI, users can include only certain stages of Auto DevOps while continuing to use their own custom
gitlab-ci.yml. This will enable teams to include just the desired jobs while taking advantage of any updates made upstream.
Until now, managing group membership on GitLab.com was a manual effort. You’re now able to use SAML SSO and manage group membership with SCIM, allowing your organization to create, remove, and update users on GitLab.com.
This is especially useful for enterprises who typically manage large numbers of users with centralized identity providers. Now, you’re able to use a provider like Azure Active Directory as the single source of truth – and feel confident that your users will be provisioned and de-provisioned automatically based on your identity provider, not by hand.
Previously, SAML-based SSO for groups required that a user sign in with both their GitLab user credentials and their identity provider. Now, a user will be able to use SSO to immediately sign in with a GitLab user linked to the configured group.
This removes the need to sign in twice, making SAML SSO more convenient and useful for enterprises using it on GitLab.com.