ruaok: Yes. I just pushed an updated and rebuilt image of PR 1390 for test.lb if you want to deploy it.
I'm now looking at front-end tests that I borked during a merge.
alastairp
_lucifer: yeah, look at every other dockerfile in metabrainz that uses a pre-defined ARG in a LABEL, and you'll see that yvanzo follows this exact patter
its... weird. but apparently they way that it has to work
oh, did _lucifer fix the babel thing??!?
!m _lucifer (and Mr_Monkey, I guess)
BrainzBot
You're doing good work, _lucifer (and Mr_Monkey, I guess)!
Mr_Monkey
I fixed it in another way that a drawback, so not as good :p
that added a drawback*
alastairp
weiiird
rebasing and testing 1424, then
Mr_Monkey: oh, I ran into something testing on my other computer. new docker uses this thing called "buildkit", and it doesn't leave behind intermediate images like old "docker build" does, so this issue that we had about having old LABELs that don't make sense isn't an issue anymore
because those intermediate layers appear to no longer exist
Mr_Monkey
Huh
But there's no ill effects to setting it to blank?
alastairp
no. I've left the "setting it to blank" in place until I can work out how buildkit fits into the grand scheme of things
It'll probably become a defult in future versions of docker, but until then let's keep the workaround in place
BrainzGit
[listenbrainz-server] alastair merged pull request #1424 (master…add-git-hash-label-last): Don't add GIT_COMMIT_SHA build to the label at the beginning of the build https://github.com/metabrainz/listenbrainz-serv...
alastairp
_lucifer: ^ fixed - can you please add the tricks for the duplicate ARG to the spark PR?
nable to reserve cache with key layer-docker-layer-caching-ListenBrainz Unit Tests-d261fe9be9433846e3ce7055d0a028c5a11ad8e664d1ce7e81b5e00730bb7eea, another job may be creating this cache.
its added only to the prod image only to avoid invalidating the entire test setup.
alastairp
right, nice
one thing - I've encountered an issue before in docker multistage builds where in a file like this, if you ask it to build test then it'll also do the items in prod
I don't know if this is something that still happens. did you see anything like it?
(sorry, I missed the fact that this was a multi-stage file)
_lucifer
yeah, i noticed that. but its only one step so i let it slide.
alastairp
run me through - why does the prod version not need java, but the test one does?
_lucifer
the prod version has java, spark and hadoop installed directly on the node
we only use docker to manage python dependencies
but i think i might be able to get that done without the docket image soon, at that point entire prod setup will be dockerless
alastairp
and you build a docker image with the dependencies and then copy them out of the docker image into the spark environment?
yeah, I think it makes sense to either run everything in docker, or nothing. but we should also think about consistency - if local dev uses docker and production doesn't, is there a risk of things working in one and not the other?
_lucifer
no the spark installation is mounted to the docker image so it runs inside the container