08:46 <eric_engestrom> mupuf: doesn't that error prevent the update of planet's page though?

09:12 <eric_engestrom> I think that `artifacts:` needs a `when: always` to upload even if the job fails

09:15 <eric_engestrom> https://gitlab.freedesktop.org/freedesktop/planet.freedesktop.org/-/merge_requests/48

09:16 <eric_engestrom> kusma: ^

09:20 <alatiera> maybe then failing to pull sources shouldn't be fatal and a failed job

09:28 <eric_engestrom> alatiera: the idea was for these errors to be visible in the pipeline, instead of each person having to go look at the log to see if something went wrong

09:28 <eric_engestrom> see https://gitlab.freedesktop.org/freedesktop/planet.freedesktop.org/-/merge_requests/34

09:29 <eric_engestrom> since gitlab doesn't have a "warning" job state, `exit_code != 0` + `allow_failures: true` are the way to do this

09:30 <alatiera> hmm yea, there's no nice solution here I guess

10:02 <eric_engestrom> hmm, I merged the artifacts fix and now they are uploaded correctly, but it looks like the Pages still isn't updated; I have no experience with Pages so I don't know how it picks up the artifacts and if there's something that needs to be done for it to pick artifacts of failed jobs as well?

10:14 <alatiera> is there a pages:deploy showing up in the pipeline?

10:15 <eric_engestrom> alatiera: this is the latest pipeline: https://gitlab.freedesktop.org/freedesktop/planet.freedesktop.org/-/pipelines/948620

10:15 <eric_engestrom> I guess not?

10:16 <alatiera> hmm, maybe it doesn't trigger with allow_failure

10:16 <eric_engestrom> ivyl: I see that you already had to deal with something similar to this a few years ago (about email being sent despite allow_failure: https://gitlab.com/gitlab-org/gitlab/-/issues/28393); in the comments there was a discussion about fixing the `allow_failure` inheritance as a first step to fixing your issue, do you know if that fix was ever merged?

10:18 <eric_engestrom> (the code in gitlab looks different now than it did when you posted your diff, but I can't tell if that means the fix was merged or if the same buggy code just got refactored)

10:18 <alatiera> https://gitlab.gnome.org/World/twig/-/pipelines/553477

10:18 <alatiera> eric_engestrom ^ that's how the jobs look when they deploy

10:18 <ivyl> eric_engestrom: I believe it was never merged. A lot of bugs filed against GitLab end up like that unless there's an enterprise client requesting the same thing.

10:18 <alatiera> gitlab makes a pages:deploy

10:19 <eric_engestrom> ivyl: yeah, that's also been my experience; unless you provide the fix yourself and make a good case for why this is good/safe/etc. things never get fixed...

10:19 <ivyl> If it still doesn't works I would guess it's just a refactor.

10:19 <ivyl> work*

10:19 <eric_engestrom> alatiera: ack, I remember seeing these in the mesa3d.org pipelines as well, but I had forgotten

10:19 <eric_engestrom> ivyl: thing is I don't know if that specific part still doesn't work or if the problem is somewhere else

10:20 <eric_engestrom> I guess I can always post an updated version of your patch as an MR and see how that goes

10:20 <ivyl> ah, I haven't followed on that in years, sorry

10:20 <eric_engestrom> (doesn't help us right now though)

10:20 <eric_engestrom> ivyl: no worries!

10:50 <eric_engestrom> issue raised about the fact `artifacts:when:on_success` does not respect `allow_failure:true`: https://gitlab.com/gitlab-org/gitlab/-/issues/420292

10:50 <eric_engestrom> making a reproducer for the pages:deploy bug and posting that in a bit

10:51 <eric_engestrom> (and the suggested blind fix)

10:59 <daniels> I would guess that pages:deploy doesn't fire when the pages job fails, because ... why would it?

11:05 <alatiera> yeap, I'd expect the same

11:13 <eric_engestrom> yeah I agree, except "why would it" -> because `allow_failure` says the job should be considered successful

12:39 <DavidHeidelberg[m]> for at least few hours, jobs are pending few minutes until triggered (even sanity job), is this expected state?

14:17 <kisak> I don't know if I'm interloping here, but I'll throw it out there anyway ... There was a minor snafu with git tags in the mesa repo over the weekend, and I don't know if dcbaker needs some admin level help to remove the mesa-23.2.0 tag from the main mesa repo, so that it's free for normal use at earliest in 2 weeks. (I don't know if there's restrictions in place or if you can change the target commitid

14:17 <kisak> of the tag without hazard)

14:49 <dcbaker> kisak: thanks, that was my first thing to ask this morning

15:04 <eric_engestrom> dcbaker, kisak: mesa-23.2.0 deleted

15:05 <dcbaker> eric_engestrom: thanks!

15:05 <eric_engestrom> (this doesn't require an admin, Maintainer+ can do this)

15:07 <eric_engestrom> btw speaking of gitlab admins: fyi gitlab has added an "assault maintainers with spam" button in issues (they labelled it "create issue based on short prompt" 🙄); I've only seen it on gitlab.com for now, but if/when it ships to everyone we'll probably need to find out how to disable it before we can safely do the update

15:07 <eric_engestrom> (LLM is an interesting tech that they keep using in all the wrong places, and having a script invent bug reports is pretty high on the list of wrong places)

15:09 <kisak> okay, thanks. I'll try to scratch out the obsolete factoid in my brain.

16:45 <ndufresne> daniels: in gst, we have a case were the shared script for creation docker images got fooled by a 500 error in the gitlab registry, it rebuilt the image for the same tag, but something in cargo changed, the new build is bad, now we have some MR working, some MR failing, have you hit this issue before ? any idea how we can make the script robust ?

16:45 <alatiera_afk[m]> ndufresne: I fixed that in the template recently

16:45 <ndufresne> - > https://gitlab.freedesktop.org/gstreamer/gstreamer/-/pipelines/946983

16:46 <alatiera_afk[m]> almost sure I updated the ref too, but I might have forgot to backport it

16:46 <ndufresne> This was 3 days ago, the windows and fedora images got rebuilt and re-uploaded, no tag was changed

16:46 <alatiera_afk[m]> oooh that's on pull hmm

16:46 <ndufresne> the script could have failed insteast of assuming 500 meant there is no image

16:47 <alatiera> yea I see what you mean now

16:48 <alatiera> it's more up to podman/buildah to throw an exit code at that

16:48 <alatiera> although, ugh this is weird

16:48 <alatiera> when they do throw an exit code we assume it's no image damn

16:51 <ndufresne> + skopeo inspect docker://registry.freedesktop.org/gstreamer/gstreamer/amd64/fedora:2023-07-17.0-main

16:51 <ndufresne> + jq '[.Digest, .Layers]'

16:51 <ndufresne> time="2023-07-28T13:40:04Z" level=fatal msg="Error parsing image name \"docker://registry.freedesktop.org/gstreamer/gstreamer/amd64/fedora:2023-07-17.0-main\": reading manifest 2023-07-17.0-main in registry.freedesktop.org/gstreamer/gstreamer/amd64/fedora: received unexpected HTTP status: 500 Internal Server Error"

16:52 <ndufresne> I'm expecting that level=fatal, and string matching "500 Internal Server Error" is feasible