The .generated files are generated by the tests that make sure the corresponding non-.generated file is up-to-date (see lib/tasks/gitlab/openapi/v2.rake for this one). I don't see how it could've been intended that this one be committed :)

The link you posted (https://gitlab.com/gitlab-org/gitlab/-/commits/master/doc/api/openapi/openapi_v2.yaml.generated) is interesting though; I did a spot-check of a dozen commits that precede 43dfda64 (including the one just before that in that list) and none of them modify/add/remove that file, so I think you found a gitlab bug 😅

What does this MR do and why?

Remove accidentally-committed generated file

Committed by accident in 43dfda64 (/cc @skundapur), and then "updated" by a bunch of commits since.

Adding a .gitignore to prevent that mistake from happening again :)

References

N/A

Screenshots or screen recordings

N/A

How to set up and validate locally

N/A

Thanks @pedropombeiro! Before I go write these tests, could you confirm that this is something reasonable to be doing?

Eric Engestrom (52cdfea6) at 03 Mar 18:06

... and 2 more commits

Eric Engestrom (c631564e) at 03 Mar 18:03

... and 129472 more commits

I had a look to see where the existing tests are so that I can add mine next to them, but I didn't manage to find them; could you point me to the right file?

Eric Engestrom (d1614a02) at 03 Mar 13:14

What does this MR do and why?

Add support for a runner to query its own details

This allows tooling that manages runners to trivially check if a runner has been modified externally and needs to be updated/re-created.

Security-wise this should not be opening any new doors: this is the information that was provided at creation so anyone who has the runner token has that information, modulo any external updates.

References

https://docs.gitlab.com/api/runners/#retrieve-runners-details

Screenshots or screen recordings

N/A

How to set up and validate locally

Calling the new GET /runners/self API with the PRIVATE-TOKEN header set to the runner's own token returns the same information as calling the existing GET /runners/:id with a PAT that has the appropriate permissions.

(not tested yet as I haven't set up a local gitlab instance; if documentation for doing this has been written since last time I looked for it, please mention it in a comment so that I can set it up 🙏)

MR acceptance checklist

• Tests needed (waiting for the idea to be approved before spending time writing them)

Eric Engestrom (4f42ee99) at 27 Feb 18:37

... and 129473 more commits

I just retried and confirmed that this is still current as of GitLab 18.8.4

But also, to whoever is responsible for that stale bot: your behaviour is pretty offensive and I hope you will look up and read any of the numerous article & blog posts about your behaviour and how it's received by everyone else, and I hope you realise that literally "doing nothing" is better for everyone (yes, including GitLab) than what you're doing.

This MR was mentioned on IRC again, and I just wanted to write down here the issue I see: a common case is for Marge to time out on a merge pipeline, and when a human looks at it, there's actually just a minute left of some job that was picked up late (typically because a user was running a bunch of long jobs that tied the runners for too long). The human will then re-assign the MR to Marge, and if needed unassign/reassign any other MRs in the queue so that they get moved back behind this MR.

This MR will kill that use-case, so it would be good to detect it. The first fix that comes to mind is to check if the current pipeline for the MR is already created by Marge, and only do this if that's not the case. This will fix the problem for Mesa CI (on freedesktop.org) as well as all the CIs that copied from it, but there might be use-cases that are not covered by that. Maybe this solution is good enough though, it's probably worth implementing here (and rebasing 😅) to see how it would look, and if there are no other objections (once the ones above are addressed) this can probably be merged :)

The code is sound, but I'm guessing maybe CI_OPEN_MERGE_REQUESTS only gets populated if the MR pipeline would be created in the target namespace, which IIRC is what happens when you're a Developer or above on the target project.

@benjamb Would you mind testing this?

1. create a test branch
2. cherry-pick the first commit git fetch https://gitlab.com/marge-org/marge-bot b2955f321c626b021ab8182baff13677a1316bc9 && git cherry-pick FETCH_HEAD
3. push that first commit to your fork
4. create a dummy merge request on this repo with only that first commit
5. (wait long enough that the MR is fully initialised; a minute should be more than enough)
6. cherry-pick the second commit git fetch https://gitlab.com/marge-org/marge-bot 9b7f333d0a0ef82c7bb60ed0124984e9e9631253 && git cherry-pick FETCH_HEAD
7. push that second commit
8. look at the pipeline tab to see if we see: a fork pipeline with the first commit, then a MR pipeline with the first commit, and then only a MR pipeline with the second commit.

If we also see a fork pipeline with the second commit, then my guess is wrong and I need to investigate more, but if what I describe in 5 is what we see, then this MR is good to go 🤞

Eric Engestrom (9b7f333d) at 20 Jun 10:03

Draft because this is not working for some reason 🤔

Eric Engestrom (6e11df98) at 19 Jun 12:11

Eric Engestrom (86951bf9) at 19 Jun 12:11

(The new condition is copied from what we do in Mesa CI)

Eric Engestrom (6e11df98) at 19 Jun 12:09

I've also split the last commit into two, so that the (new) last commit can be a template for other MRs wanting to add another timeout action.