Gosia Ksionek (12a4add5) at 18 Mar 17:33

Gosia Ksionek (4eccb16e) at 18 Mar 17:32

... and 1 more commit

What does this MR do and why?

This batches MergeRequestDiffCommit.create_bulk inserts into slices of 1,000 rows to prevent excessively long SQL INSERT statements. Currently, all commits for a merge request diff are inserted in a single query. For large pushes this produces SQL statements with thousands of bind parameters, which account for ~50% of overly-long SQL statements (https://gitlab.com/gitlab-org/gitlab/-/work_items/499189#note_2316720774) in production.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #499189

Gosia Ksionek (592f4c21) at 18 Mar 15:50

... and 1001 more commits

issues to tackle in 18.11:

---
display: table
fields: state, title, assignees, milestone, labels("workflow*"), updatedAt
limit: 100
---
group = "gitlab-org" and label = "wi-workstream-5::outstanding" and type = issue and state = opened and epic = &15524 and milestone=%18.11

Gosia Ksionek (a51724a9) at 18 Mar 12:50

... and 434 more commits

Gosia Ksionek (14fce716) at 18 Mar 12:42

Gosia Ksionek (551c3e7c) at 18 Mar 12:16

Thank you for working on this! Approving 🚢

What does this MR do and why?

Allows to expose more entities as part of the WorkItem REST API. This adds:

• health_status
• color
• progress
• iteration

References

Screenshots or screen recordings

How to set up and validate locally

1. Enable the FF: work_item_rest_api, and okrs_mvc (which has the progress widget)
2. For colors you need to test it on epics
3. Use the following URL for testing he new features: and change the full_path for the namespace you want to test it on:

• http://gdk.test:3000/api/v4/namespaces/gitlab/-/work_items?features=health_status,color,iteration,progress

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Suggestion: I would suggest checking policy (if user can interact with this policy) before exposing details about it (that it's not pipeline_execution_schedule policy)

I have couple of small remarks and questions @Andyschoenen :)

question (non-blocking): in what case that would return nil?

suggestion (blocking): Shouldn't we use authorized_find here?

question (blocking): we have the same check in the TestRunService, is it on purpose?

Thank you for working on this! Approving 🚢