10:59 <pinchartl> is there a way, in gitlab CI job rules, to set the compare_to to the branch base when pushing a new branch ?

11:07 <pinchartl> also, is there a way to run jobs for every commit from the base, instead of running them on the branch head only ? the goal is to catch bisection breakages

11:10 <pinchartl> apparently not https://gitlab.com/gitlab-org/gitlab/-/issues/25148

11:10 <pinchartl> bentiss: you even commented on that issue :-)

11:11 <pinchartl> looks like I'll have to implement this manually

11:23 <pinchartl> would anyone have implemented a script to test all commits in a branch by any chance ? it shouldn't be hard to do but I'd rather not reinvent the wheel

11:44 <bentiss> pinchartl: I have that on my CI: https://gitlab.freedesktop.org/bentiss/gitlab-kernel-ci/-/blob/master/.gitlab-ci.yml?ref_type=heads#L243 and look for history_start_stage and history_next_stage -> basically, history_start finds the first commit to test, then force pushes the current branch, and history_next follows the next commit up to the previous HEAD

11:45 <bentiss> pinchartl: but I'm still off til next Monday, so likely not being able to help you on that right now

11:46 <pinchartl> bentiss: thanks

11:47 <pinchartl> interesting, so your CI pipeline triggers the run of another CI pipeline

11:55 <bentiss> yeah, the point is to have each commit its green badge

12:08 <mupuf> pinchartl: I had the same question, and this is definitely something I want in ci-tron

12:08 <mupuf> when using shelly plugs to control each DUT, we can get the full run's energy usage

12:08 <mupuf> then we can check the current carbon intensity for the country the machine is in

12:08 <mupuf> and the price

12:09 <pinchartl> it would be good to get the same for the CPU time used on the fd.o shared runners

12:10 <mupuf> then boom, you get: Run consumed 0.123kWh (~0.05 euros, 30g of CO2)

12:10 <mupuf> that's a little harder, unless you trust RAPL ;)

12:10 <mupuf> or AMD's equivalent

12:20 <eric_engestrom> pinchartl: re- `compare_to:`, if you try to use it be aware that they designed it badly, to the point where it cannot be used in mesa because we allow people to fork the repo (we even rely on it) and they didn't think about that use case: https://gitlab.com/gitlab-org/gitlab/-/issues/424584

12:20 <eric_engestrom> DavidHeidelberg: did you delete this file in the last couple of days? https://s3.freedesktop.org/mesa-lava/gfx-ci/linux/v6.6.4-for-mesa-ci-e4f4c500f7fb/arm64/Image

12:20 <eric_engestrom> (or auto-delete from a script or something)

12:23 <eric_engestrom> the rootfs builds worked until at least 2 days ago; I'm not sure if I ran one yesterday, but today they are broken because the file has been deleted

12:23 <pinchartl> eric_engestrom: thanks. it seems fairly badly designed indeed

12:23 <pinchartl> I would have expected gitlab to do much better in this area, it's disappointing

12:24 <eric_engestrom> yeah :(

12:28 <martink> heya, I have Q re gitlab.freedesktop.org access tokens: so my original access token expired, and I'm trying to create a new one, but the token I get each time is not a valid base64 string -- it has "-" in it, and so docker login does not like that when trying to login to registry.freedesktop.org. Clearly I'm missing something

12:29 <pinchartl> every time I run into a problem and find an open issue, it's several years old, still open, and ends with people pinging every few months with no reply from gitlab.com

12:34 <martink> it's weird, as if I'm using the wrong token filed to copy from in the gitlab token generation wizard. Each time I get a new token starting with "glpat-" which clearly is not valid base64.

12:36 <pinchartl> martink: how do you create the new toek ?

12:36 <pinchartl> *token

12:36 <pinchartl> to push to the registry, you need a deploy token, not a project access token as far as I know

12:37 <martink> pinchartl: profile/personal_access_tokens

12:37 <pinchartl> /-/settings/repository -> Deploy tokens

12:38 <pinchartl> make sure to tick both 'read_registry' and 'write_registry', even if you only want to push, as the push command needs to read the registry to see if the image is already present

12:38 <martink> pinchartl: I need it for registry access alone, so I have just read_registry and write_registry, and nothing else

12:40 <pinchartl> can you try to create a project deploy token instead of a personal access token ?

12:41 <pinchartl> or possibly remove the glpat- prefix from your personal access token ?

12:41 <pinchartl> (the latter is just a wild guess)

12:43 <martink> pinchartl: I just tried -/settings/access_tokens and it keeps producing "gplat-" tokens, both visually in the token field and in the clipboard.

12:44 <pinchartl> /-/settings/repository -> Deploy tokens

12:49 <martink> pinchartl: Ok, tried that -- generated tokens there are valid base64, but docker login still does not like them, as by eyeballing them they're just too short.

12:50 <martink> (the old expired token was notably longer)

12:51 <pinchartl> I've used a deploy token successfully with docker, so I don't know what else to say :-S

12:52 <pinchartl> $ docker login -u $user -p $token registry.freedesktop.org

12:52 <pinchartl> where $token is the token and $user the user name you specified when creating the otken

12:53 <pinchartl> eric_engestrom: your bug report has very nicely been classified as abuse by an ML model, lovely

12:54 <martink> pinchartl: doh, operator error: I was trying to use the token in the json config, instead of passing it on the CLI as -p. My bad. Thank you for the patience!

12:54 <pinchartl> if you don't use compare_to in mesa, what do you use to skip jobs for new branches ?

12:54 <pinchartl> martink: you're welcome

12:55 <pinchartl> eric_engestrom: or does pushing a new branch to a fork triggers all tests ?

13:11 <emersion> getting a 500 when posting a GL comment

13:50 <pinchartl> bentiss: I'm puzzled. your CI pipeline seems to assume that $CI_COMMIT_SHA always points to the head of the branch being tested. when you force-push intermediate commits, doesn't that change CI_COMMIT_SHA in the pipeline that gets triggered ?

13:50 <pinchartl> or do I understand the code incorrectly ? I'm looking at

13:50 <pinchartl> NEXT_COMMIT=$(git log origin/$CI_COMMIT_REF_NAME...$CI_COMMIT_SHA --pretty=format:%H | tail -1)

13:52 <bentiss> pinchartl: there is an after_script that pushes back the head after the intermediate commit

13:56 <pinchartl> aahhhhhh

13:56 <pinchartl> isn't that racy though ?

14:00 <pinchartl> but even with the after_script, the history_next_stage job is triggered by the git push that pushes the intermediate commit

14:01 <pinchartl> so CI_COMMIT_SHA will be the intermediate commit for that pipeline

14:01 <pinchartl> ah got it

14:01 <pinchartl> you're using ... not ..

14:02 <pinchartl> origin/$CI_COMMIT_REF_NAME is actually more recent than $CI_COMMIT_SHA

14:02 <pinchartl> it's still racy though, but the race is likely impossible to hit in practice

14:23 <eric_engestrom> pinchartl: re- some ML model classifying my report as abuse, I saw that back then, but I have no idea what triggered it, and even if I did, I assume replying would not help, I would have to copy/paste into a new issue with that one word that triggers it modified, and I don't have the patience to play games with whatever fucking "AI" they got scammed into hooking up into their issue tracker...

14:24 <eric_engestrom> pinchartl: re- new branches, they trigger all the jobs right now, we didn't find a way to fix that (they need to fix `compare_to`, that will be the fix IMO)

14:28 <pinchartl> eric_engestrom: thanks

15:17 <DavidHeidelberg> Can I set unlimitwd eypiration to specific files within some S3 bucket?

15:17 <DavidHeidelberg> *expiration

15:23 <enunes> eric_engestrom: DavidHeidelberg: saw this discussion now, I'm hitting the v6.6.4-for-mesa-ci-e4f4c500f7fb missing files as well trying to re-enable my lab

15:24 <DavidHeidelberg> rebuild triggered :/ ~ 12 min ETA

15:27 <DavidHeidelberg> eric_engestrom: nah, probably some autodelete. It seems to me that I need to explicitly set expiration to the kernels which are used in CI

15:27 <DavidHeidelberg> s/used/actively used/

15:30 <eric_engestrom> DavidHeidelberg: I think you should disable auto-delete for all of them; it's not much storage space used, and trying to auto-detect which ones are used will always have some case where it fails

15:36 <eric_engestrom> (btw, thanks for re-generating that kernel 🙏)

16:03 <DavidHeidelberg> Sometimes I run bisect there, so lot of artifacts.. But still better than failure

18:53 <daniels> mesa-lava gets autodeleted because it has everything - we can make a separate bucket with no expiration or do what the rootfs/etc pulls do and re-upload to s3 if something’s missing

18:54 <daniels> (s3 is assumed to be ephemeral, we have no backups etc)