Pipelines for Merged Results
Pipelines for Merged Results
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.
Suggest changes to multiple lines
Suggest changes to multiple lines
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
Scoped Labels
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::iOS, platform::Android, 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::development, workflow::review, and 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.
More thorough Container Registry cleanup
More thorough Container Registry cleanup
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.
Purchase add-on CI Runner minutes
Purchase add-on CI Runner minutes
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.
Composable Auto DevOps
Composable Auto DevOps
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.
Automatically manage group members on GitLab.com using SCIM
Automatically manage group members on GitLab.com using SCIM
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.
Sign in to GitLab.com with your own SAML provider
Sign in to GitLab.com with your own SAML provider
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.
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