Follow-up from "Use milestone ID instead of name for release API"

Currently you can only specify milestones or milestone_ids on a given release with the API to update the milestones.

To fix this, MilestoneFinder needs to treat milestone titles and milestone ids as an OR relationship, instead of an AND as it currently does

The following discussion from !111215 (merged) should be addressed:

• @acook.gitlab started a discussion: (+8 comments)

added bugfunctional grouprelease [DEPRECATED] typebug labels

added devopsrelease [DEPRECATED] sectionops labels

mentioned in issue gitlab-org/quality/triage-reports#11205 (closed)

mentioned in issue gitlab-org/quality/triage-reports#11285 (closed)

mentioned in issue gitlab-org/quality/triage-reports#11375 (closed)

marked this issue as blocking #326897

@nagyv-gitlab this one would be a blocker for Grand parent group milestones are not displayed... (#326897). Maybe you'll want to schedule it at some point.

Setting severity4 because this issue isn't a problem for anyone on it's own, but priority2 because it blocks another bug.

@vshushlin Would this be a breaking change? (Changing query parameters from AND to OR) Do we know of any use cases that rely on the "OR" statement?

@nagyv-gitlab it was just introduced, so nobody should depend on it yet. But it's a good point, probably we don't want to postpone it too much so people won't use the wrong behavior.

@vshushlin (me having refinement DRI hat on 🎩) from the issue description and linked MR discussion it seems to be pretty clear what we have to do here - I'd say a weight 1 or max 2.

Can you confirm? If so, I'd like to move it from workflowrefinement to workflowready for development.

Thanks, @timofurrer, yep, 2 following the https://about.gitlab.com/handbook/engineering/development/ops/configure/#weights sounds good 👍

@vshushlin question, have we missed our window regarding:

it was just introduced, so nobody should depend on it yet. But it's a good point, probably we don't want to postpone it too much so people won't use the wrong behavior.

if not, @nagyv-gitlab I'm wondering if we should prioritize this (even though it's severity4 so we can unblock the severity3 bug that it blocks.

Changing severity

Hunter Stewart (@hustewart) gitlab@mg.gitlab.com ezt írta (időpont: 2023. nov. 6., H 19:58):

...

Hunter Stewart https://gitlab.com/hustewart commented on a discussion #391332 (comment 1636065838):

@vshushlin https://gitlab.com/vshushlin question, have we missed our window regarding:

it was just introduced, so nobody should depend on it yet. But it's a good point, probably we don't want to postpone it too much so people won't use the wrong behavior.

if not, @nagyv-gitlab https://gitlab.com/nagyv-gitlab I'm wondering if we should prioritize this (even though it's severity4 https://gitlab.com/gitlab-org/gitlab/-/issues?label_name=severity%3A%3A4 so we can unblock the severity3 https://gitlab.com/gitlab-org/gitlab/-/issues?label_name=severity%3A%3A3 bug #326897 blocks.

— Reply to this email directly or view it on GitLab #391332 (comment 1636065838). You're receiving this email because you have been mentioned on gitlab.com. Unsubscribe https://gitlab.com/-/sent_notifications/REDACTED/unsubscribe from this thread · Manage all notifications https://gitlab.com/-/profile/notifications · Help https://gitlab.com/help

Setting a due date before the dependent bug.

Viktor Nagy vnagy@gitlab.com ezt írta (időpont: 2023. nov. 8., Sze 12:37):

...

Changing severity

/label severity3

Hunter Stewart (@hustewart) gitlab@mg.gitlab.com ezt írta (időpont: 2023. nov. 6., H 19:58):

Hunter Stewart https://gitlab.com/hustewart commented on a discussion #391332 (comment 1636065838):

@vshushlin https://gitlab.com/vshushlin question, have we missed our window regarding:

it was just introduced, so nobody should depend on it yet. But it's a good point, probably we don't want to postpone it too much so people won't use the wrong behavior.

if not, @nagyv-gitlab https://gitlab.com/nagyv-gitlab I'm wondering if we should prioritize this (even though it's severity4 https://gitlab.com/gitlab-org/gitlab/-/issues?label_name=severity%3A%3A4 so we can unblock the severity3 https://gitlab.com/gitlab-org/gitlab/-/issues?label_name=severity%3A%3A3 bug #326897 blocks.

— Reply to this email directly or view it on GitLab #391332 (comment 1636065838). You're receiving this email because you have been mentioned on gitlab.com. Unsubscribe https://gitlab.com/-/sent_notifications/REDACTED/unsubscribe from this thread · Manage all notifications https://gitlab.com/-/profile/notifications · Help https://gitlab.com/help

@hustewart I think it's ok to implement this now. I don't expect anyone to actually depend on that behaviour.

Hi @nagyv-gitlab @hustewart I'm just moving this up the priority list in the bug-squash dashboard since it is blocking Grand parent group milestones are not displayed... (#326897) that was top of the list before.

changed milestone to %Backlog

added priority2 severity4 labels

added groupconfigure [DEPRECATED] workflowrefinement labels and removed grouprelease [DEPRECATED] label

added devopsconfigure [DEPRECATED] label and removed devopsrelease [DEPRECATED] label

added workflowready for design label and removed workflowrefinement label

added workflowproblem validation label and removed workflowready for design label

added workflowrefinement label and removed workflowproblem validation label

added workflowready for development label and removed workflowrefinement label

set weight to 2

added groupenvironments label and removed groupconfigure [DEPRECATED] label

added devopsdeploy label and removed devopsconfigure [DEPRECATED] label

mentioned in issue gitlab-org/quality/triage-reports#11808 (closed)

mentioned in issue gitlab-org/quality/triage-reports#11910 (closed)

mentioned in issue gitlab-org/quality/triage-reports#11999 (closed)

mentioned in issue gitlab-org/quality/triage-reports#12073 (closed)

mentioned in issue gitlab-org/quality/triage-reports#12162 (closed)

mentioned in issue gitlab-org/quality/triage-reports#12225 (closed)

added Seeking community contributions environmentsparked labels

@nagyv-gitlab thanks for adding the Seeking community contributions label!

This issue's description does not seem to have a section for "Implementation Guide". Please consider adding one, because it makes a big difference for contributors. This section can be brief but must have clear technical guidance, like:

• Hints on lines of code which may need changing
• Hints on similar code/patterns that can be leveraged
• Suggestions for test coverage
• Ideas for breaking up the merge requests into iterative chunks

This message was generated automatically. You're welcome to improve it.

mentioned in issue gitlab-org/quality/triage-reports#12354 (closed)

mentioned in issue gitlab-org/quality/triage-reports#12427 (closed)

removed milestone %Backlog

changed milestone to %16.0

changed milestone to %16.1

removed milestone %16.1

mentioned in issue gitlab-org/quality/triage-reports#12490 (closed)

changed milestone to %Backlog

mentioned in issue gitlab-org/quality/triage-reports#12583 (closed)

added SLOMissed label

mentioned in issue #326897

added severity3 label and removed severity4 label

added sectioncd label and removed sectionops label

I'm adding the Q4 label and setting a due date

changed due date to February 19, 2024

added DeployFY24Q4 Goal label

mentioned in commit gitlab-community/gitlab@3f0dd600

mentioned in merge request !139809 (merged)

mentioned in commit gitlab-community/gitlab@54efa4f2

assigned to @hustewart

added workflowin dev label and removed workflowready for development label

removed Seeking community contributions label

@acook.gitlab @vshushlin In order to priortize this I'm trying to understand what problem this solves and how it blocks #326897

If it works with either ID or Title, what do get get by allowing the array to include both ID and Title? Couldn't the caller be OK providing one type or the other?

Also it looks like #326897 should be able to be resolved by using include_ancestors on the frontend. I don't understand how this issue blocks the frontend from doing that, could you help explain?

Thank you!

@hustewart Sorry, but I already forgot my reasoning for this issue 🙈

I would try to implement Grand parent group milestones are not displayed... (#326897) • Unassigned • Backlog • On track and see if this one is actually a blocker, maybe it's not.

Allen may remember it better.

@vshushlin No worries, I wouldn't remember either but figured worth an ask! I agree just trying to implement the other is probably best. Thanks for responding!

I think my initial plan here is to implement #326897 and if it works OK then I'm just going to close this issue.

I can't remember my reasoning here either, your plan sounds like a reasonable path forward. If it becomes a blocker we can revisit

Thanks everyone. Interesting stuff I found and posted over there in the Async update just in case you are curious: #326897 (comment 1856101517)

Async Update

confidence: 50% complete: 0%

Right now I have decided to try and implement a solution for Grand parent group milestones are not displayed... (#326897) to help drive the research necessary to work on this one. This one is kind of somewhere between workflowrefinement and workflowin dev so I'll leave the labels alone for now.

It's possible this issue will be subsumed under Grand parent group milestones are not displayed... (#326897) - if it is I'll close this one.

Async update

It turns out Grand parent group milestones are not displayed... (#326897) is a feature request as the docs state:

Group milestones associated with the project may be specified in the milestones array for Create a release and Update a release API calls. Only milestones associated with the project’s group may be specified, and adding milestones for ancestor groups raises an error. (emphasis mine)

Since this issue only existed in the context of trying to unblock that, and it turns out it's a feature and not a bug request, this issue will be closed.

closed