Reintroduce recursive_approach_for_all_projects default-enabled
What does this MR do?
Reintroduced the recursive_approach_for_all_projects
feature flag which was removed in !55043 (merged). It also default-enables the FF so as not to disrupt GitLab.com or self-managed instances that are not experiencing problems.
However, this gives customers that are experiencing performance problems after upgrading a temporary path to unblock. Then we can address the performance problems iteratively.
Related to #334251 (closed).
Screenshots (strongly suggested)
Does this MR meet the acceptance criteria?
Conformity
-
I have included changelog trailers, or none are needed. (Does this MR need a changelog?) -
I have added/updated documentation, or it's not needed. (Is documentation required?) -
I have properly separated EE content from FOSS, or this MR is FOSS only. (Where should EE code go?) -
I have added information for database reviewers in the MR description, or it's not needed. (Does this MR have database related changes?) -
I have self-reviewed this MR per code review guidelines. -
This MR does not harm performance, or I have asked a reviewer to help assess the performance impact. (Merge request performance guidelines) -
I have followed the style guides. -
This change is backwards compatible across updates, or this does not apply.
Availability and Testing
-
I have added/updated tests following the Testing Guide, or it's not needed. (Consider all test levels. See the Test Planning Process.) -
I have tested this MR in all supported browsers, or it's not needed. -
I have informed the Infrastructure department of a default or new setting change per definition of done, or it's not needed.
Security
Does this MR contain changes to processing or storing of credentials or tokens, authorization and authentication methods or other items described in the security review guidelines? If not, then delete this Security section.
-
Label as security and @ mention @gitlab-com/gl-security/appsec
-
The MR includes necessary changes to maintain consistency between UI, API, email, or other methods -
Security reports checked/validated by a reviewer from the AppSec team
Merge request reports
Activity
mentioned in issue #334251 (closed)
- Resolved by Etienne Baqué
@cwiesner Do you have the bandwidth to review this, please? I'm not super familiar with this area and I couldn't revert the spec changes verbatim due to more recent code changes. I want to be sure we're not introducing some other regression.
- A deleted user
added groupfulfillment DEPRECATED label
- A deleted user
added backend feature flag labels
Reviewer roulette
Changes that require review have been detected!
Please refer to the table below for assigning reviewers and maintainers suggested by Danger in the specified category:
Category Reviewer Maintainer backend Hordur Freyr Yngvason ( @hfyngvason
) (UTC-4, 1 hour ahead of@dblessing
)Etienne Baqué ( @ebaque
) (UTC+2, 7 hours ahead of@dblessing
)To spread load more evenly across eligible reviewers, Danger has picked a candidate for each review slot, based on their timezone. Feel free to override these selections if you think someone else would be better-suited or use the GitLab Review Workload Dashboard to find other available reviewers.
To read more on how to use the reviewer roulette, please take a look at the Engineering workflow and code review guidelines. Please consider assigning a reviewer or maintainer who is a domain expert in the area of the merge request.
Once you've decided who will review this merge request, assign them as a reviewer! Danger does not automatically notify them for you.
If needed, you can retry the
danger-review
job that generated this comment.Generated by
🚫 DangerAdding priority labels aligned with the issue: #334251 (closed)
added regression typebug labels
added regression:13.10 label
assigned to @dblessing
changed milestone to %14.1
requested review from @allison.browne
mentioned in issue gitlab-com/www-gitlab-com#7734 (moved)
- Resolved by Etienne Baqué
- Resolved by Drew Blessing
- Resolved by Drew Blessing
- Resolved by Etienne Baqué
It also default-enables the FF so as not to disrupt GitLab.com or self-managed instances that are not experiencing problems.
However, this gives customers that are experiencing performance problems after upgrading a temporary path to unblock. Then we can address the performance problems iteratively.
Are there any GitLab.com performance issues?
@dblessing, I'm wondering what the drawbacks are to making this flag default disabled? Since that would require less manual interventions by users. Are we seeing a performance enhancement in some cases but not others?
Edited by Allison Browne
removed review request for @allison.browne
mentioned in issue #334817 (closed)
- Resolved by Drew Blessing
requested review from @ebaque
FYI @jameslopez @cwiesner from #334251 (closed)
enabled an automatic merge when the pipeline for 142d4630 succeeds
mentioned in commit 18d2c779
@mbruemmer @mayra-cabrera Per https://gitlab.com/gitlab-org/release/tasks/-/issues/2592 I am adding labels to pick this into 13.12 and 14.0. Please correct if this is wrong.
@dblessing That's correct. We estimate to prepare patch releases for 13.12% and 14.0% early next week.
added Pick into 13.12 Pick into 14.0 labels
added workflowstaging label
added workflowcanary label and removed workflowstaging label
added workflowproduction label and removed workflowcanary label
mentioned in issue #331429 (closed)
mentioned in issue #335064 (closed)
mentioned in merge request !65296 (merged)
mentioned in issue gitlab-org/release/tasks#2642 (closed)
mentioned in issue #334004 (closed)
@dblessing This merge request could not automatically be picked into
13-12-stable-ee
for13.12.7-ee
and will need manual intervention.Create a new merge request targeting the
13-12-stable-ee-patch-7
branch in order to have this MR included in !65366 (merged).Please follow the Process for Developers.
removed Pick into 13.12 label
mentioned in merge request !65366 (merged)
mentioned in merge request !65430 (merged)
mentioned in commit bedeefdc
mentioned in commit e3ac0395