Move required pipeline configuration to Ultimate

changed milestone to %15.0

assigned to @dennis and @sam.white

changed the description

mentioned in merge request !80199 (merged)

@dennis, please can you add a type label to this issue to help with issue discovery in issue reports.

added auto updated label

Hi @dennis,

Please add labels to your issue, this aids categorization and locating issues in the future.

Thanks for your help!

You are welcome to help improve this comment.

changed the description

added Category:Compliance Management Enterprise Edition GitLab Ultimate devopsmanage groupcompliance sectiondev typemaintenance labels

added GitLab Premium label

added backend label

added Next Up label

mentioned in issue gitlab-org/manage/general-discussion#17405

created branch 352316-move-required-pipeline-configuration-to-ultimate to address this issue

mentioned in merge request !84104 (merged)

Customer is bummed to see this going to Ultimate. Is there an alternative or API/custom script for premium customers?

Seconding this one @dennis - do we have any recommendations for our Premium customers relying on this feature?

@jrandazzo @taylor @cmaki1

I understand the frustration, so maybe I can provide some background on why we're making the move. This will make our feature tiering more consistent with our pricing themes, since the majority of our Compliance capabilities are in Ultimate today. Beyond this feature, there are lots of other capabilities like Compliance Framework Pipelines and others that I think would provide a lot of value in that tier.

As for what Premium customers can do in the meantime, as an alternative, I'd suggest they could put their required pipeline contents in a yml file and then ensure that it is included in any of the relevant projects with an include or as a template statement in the pipeline. This could be done manually or potentially with a sort of bot that iterates through projects, reads the .gitlab-ci.yml file, and creates an MR to add the template if the required file is absent.

cc @dennis

@stkerr One of my customers has concerns with not only losing this specific Premium content but how often this up-tier motion will occurr going forward. Would you be open to speaking with the customer?

@gitlab-org/manage/compliance/backend is anyone available to help refine this? This needs to happen in %15.0 and there is an additional requirement noted:

GitLab will preserve a way via feature flag or another similar capability of enabling this for individual Premium customers as needed (see requirement)

@dennis This is quite an unusual request. If a feature is marked for deprecation and removal for premium customers, but not ultimate, it's not really a deprecation and removal, right? It's an uptiering.

GitLab will preserve a way via feature flag or another similar capability of enabling this for individual Premium customers as needed (see requirement)

As far as I'm aware there aren't any current examples of "This is an Ultimate feature, except for premium customer X". (Please prove me wrong if I am, as it'll give me an example to work with.) Development feature flags are not designed for this purpose. Which makes weighing this a bit tricky I don't see this sailing through code review very easily for this reason.

Moving the feature to Ultimate is a weight but I'm not currently sure of the best way to uptier a feature whilst preserving the functionality for certain customers.

@stkerr I'm keen for your thoughts here, if you have any. Have you been involved in an feature uptiering before that retained functionality for certain lower-tiered customers?

@mwoolf that's a great point and I agree it's highly unusual, I'd also be curious on @stkerr's thought on this. Thanks for raising it!

True, feature flag doesn't seem to be an ideal candidate for this. I've worked on projects where such requests were common and we used to keep a Redis list of allowlisted group_ids or user_ids whatever was relevant for the feature and used that as a condition to decide the feature is available or not. So something like:

License.feature_available?(:foo_feature) || Gitlab::Redis::SharedState.with { |redis| redis.sismember(`allowlisted_group_ids_for_foo_feature`, `group_id`) }

Yeah, I'm certain from a technical point of view we could do this. I'm just not sure that we should.

I've never seen GitLab allow access to an ultimate feature to a premium customer. My understanding (as a non-sales and non-product person) is that we don't do this. If a customer values something in a higher tier, then it's up to us to make the business case to that customer for an upgrade. How we handle this in the case of feature uptiering is unclear to me.

@mwoolf @dennis @huzaifaiftikhar1 I spoke with @ogolowinski earlier about this and we agreed to remove the requirement about a feature flag for switching specific customers - this issue will now be a straight uptier. I've updated the issue description to strikethrough that item.

We made the decision since a feature flag would enable a Premium self-managed user to enable themselves, defeating the point of uptiering, and due to the technical concerns and challenges that were raised.

Great, thanks for clarifying that @stkerr!

Uptiering an existing feature is a . Moving to workflowscheduling

Oh actually, moving to workflowready for development since we already have a milestone

Thanks for clarifying @stkerr.

@huzaifaiftikhar1 I was thinking you could take this on for %15.0. Thoughts? Let me know if you have any questions or concerns!

Definitely, I should be able to take this up in %15.0

added workflowplanning breakdown label

unassigned @sam.white

changed the description

added workflowscheduling label and removed workflowplanning breakdown label

set weight to 1

added workflowready for development label and removed workflowscheduling label

assigned to @huzaifaiftikhar1 and unassigned @dennis

@dennis @stkerr do we have any idea on how many customers might be affected? Particularly on SaaS?

Brief context: I'm working on prepping support for 15.0 removals/breaking changes via gitlab-com/support&197 (closed)

mentioned in epic gitlab-com/support&197 (closed)

added breaking change label

added workflowin dev label and removed workflowready for development label

removed Next Up label

mentioned in merge request !85475 (merged)

Created an MR !85475 (merged), moving to workflowin review

added workflowin review label and removed workflowin dev label

A current Premium customer reached out, "In the gitlab 15 breaking changes document: https://about.gitlab.com/blog/2022/04/18/gitlab-releases-15-breaking-changes/ It states that “required pipeline configuration” is moving from premium to ultimate. Is this correct? If so, it means that a feature we have been paying for and using in most of our pipelines is being removed, which is totally unacceptable.

Please advise what we should do to avoid most of our pipelines from being broken"

Do you have any feedback or advice I can provide for this customer?

added customer label

The MR !85475 (merged) has been merged. Closing the issues as we cannot verify this change on GitLab.com production.

closed

A Premium (Self-managed) customer reached out with the following message today.

We have just discovered this situation over here: Move required pipeline configuration to Ultimate (#352316 (closed)) · Issues · GitLab.org / GitLab · GitLab And are not very happy with this and the rationale seems a bit dodgy to tbh. The workaround is also not an option for us.

Is this the only solution for them to upgrade to Ultimate or is there another way apart from the known workaround? Rightly so, they are asking whether GitLab is planning to move further features from Premium to Ultimate, which could force clients to upgrade during their contract term?

I appreciate any advice for the client.

CC: @nkavulek1 @jvpotter

Move required pipeline configuration to Ultimate

Overview

Proposal

Rationale

Designs

Child items ...

Activity