This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-01-13
Channels
- # admin-announcements (1)
- # announcements (40)
- # aws (2)
- # babashka (46)
- # babashka-sci-dev (106)
- # beginners (31)
- # cider (5)
- # circleci (2)
- # clj-kondo (48)
- # clojure (118)
- # clojure-belgium (1)
- # clojure-chicago (3)
- # clojure-europe (19)
- # clojure-ireland (3)
- # clojure-losangeles (2)
- # clojure-nl (2)
- # clojure-spec (10)
- # clojure-uk (4)
- # clojurescript (18)
- # community-development (5)
- # core-async (159)
- # cursive (16)
- # datomic (16)
- # etaoin (1)
- # fulcro (21)
- # funcool (14)
- # graalvm (5)
- # gratitude (4)
- # holy-lambda (28)
- # jobs (1)
- # jobs-discuss (1)
- # kaocha (1)
- # lsp (12)
- # malli (21)
- # meander (12)
- # music (1)
- # off-topic (8)
- # portal (5)
- # react (18)
- # reitit (1)
- # releases (4)
- # remote-jobs (1)
- # shadow-cljs (56)
- # timbre (4)
@cap10morgan the condition https://github.com/babashka/babashka/blob/master/.circleci/script/docker#L47 would never be true right? As we set the var externally to linux/amd64,linux/arm64
?
I’ll look into this shortly
Thanks!
so yeah I think this is a holdover from the first approach of building each platform separately and then uploading a manifest
I'll figure out a fix for it and put up a PR
think this should do it: https://github.com/babashka/babashka/pull/1141
i think we dont have any alpine images since 0.7.2 😞
Has anyone complained? ;) I ask half in jest as a maintainer of the clojure Docker images who has seriously considered dropping the alpine variants lately.
Well i just stumbled upon it when someone wanted to download alpine images and i could not find the alpine ones for the new versions
last one pushed is 0.7.0-alpine which is the one before our change. alpine would be more useful for bb compared to clojure as mostly they are the final image unlike for clojure where probably the final image is from openjdk or something 😄
Yeah. And bb is nice to minimize all the way :)
Fun fact: we actually had FROM scratch
but then it broke someone's jenkins that expected to have cd at least 😛 then we needed curl to be there too
Hmm, no arm64 version of pod-babashka-aws, eh? Is that a big change to support?
e.g. does bb need to learn how to resolve platform-specific pods? or would it just be a matter of building and publishing it?
oh never mind, you already answered my question here: https://github.com/babashka/pod-babashka-aws/issues/46
I can work on that PR!
looks like it's almost done anyway
@cap10morgan There is an open issue for pod-babashka-aws and pretty easy to support, just needs the work to be done
@cap10morgan why did we have linux-foo
before and now you are matching on linux/foo
in PR 1141?
@borkdude Just answered on GitHub but I can copy-paste it here: That should have already been in there, but it comes from the fact that docker platform strings look like `os/arch` while GraalVM and babashka use `os-arch`. There was a time when I was using the hyphenated form in this env var, but that was no longer the case by the time the original PR was merged and I just missed converting this one b/c it was never being run anyway.
You'll notice the other platform values (the env var's default and the list we set it to in .circleci/config.yml
) are all os/arch
@rahul080327 @cap10morgan https://app.circleci.com/jobs/github/babashka/babashka/25392?utm_campaign=workflow-failed&utm_medium=email&utm_source=notification
having a look now
that's weird...
either intermittent or an upstream bug seems like
trying to setup a buildx builder instance
shoudl we just add a --push to buildx @cap10morgan?
yeah probably
I can do that
oh, although... that would push snapshots too. do we want that?
but lets parameterize the tagging in the buildx too
based on if its a snapshot or not
yeah its a weird error, better to let buildx push
snapshots => babashka/babashka:alpine others => babashka/babashka:<version>-alpine
ah yes, the long day is taking a toll on me
ok, yeah, I was just reversing that 🙂
when snapshot is false its just alpine
I'll continue reversing it
thanks for that @borkdude
alpine
is basically latest
for alpine
yes checked now they have a SNAPSHOT in the tag
all of that coming shortly
@cap10morgan if you feel like it have a go at moving them to a bb script too, @borkdude and I discussed that its good enough complexity to boostrap maybe 😄
hehe, tempting!
or even bb tasks
I need to get this arm64 pod-babashka-aws PR together first, but then I might just take a crack at it 🙂
ok that stuff is pushed
would you open another PR?
yep, once I remember how when GH isn't suggesting it :rolling_on_the_floor_laughing:
found it
i guess you need to rebase?
guess so, one sec
phew, ok. cleaned up
will the tag change after the buildx work? wasnt that what was failing before?
yes b/c it's just one platform
I can make it consistent anyway if you want tho
looks okay to me but what was causing the last error? babashka/babashka:alpine not found one?
oh, d'oh. yeah, b/c it's pushing and not loading now. yeah, you're right, it needs the full command again.
i feel we should just use good old build here
buildx is overkill here
ehhh, yeah. maybe. it's the future and consistent w/ the rest. might even be what you get anyway at this point in the build script given what comes before.
im fine with the control flow here, just can use build?
it will likely be buildx anyway
i guess currently it doesnt like things built with buildx and the being pushed seperately
maybe have a TODO and we can revisit?
hopefully fixed in latest commit
what would the TODO be?
this works and is likely a change they'll require eventually anyway
yeah this looks better, TODO was using build and revist when docker is happy mixing buildx and builds
then do you wanna put the above build in the else? its buidling twice now i guess
when its not a snapshot
or it could be cached away :thinking_face: dunno my head spins at these build layer caching nowadays
yep looks good! thanks @cap10morgan
excellent
so for the pod-babashka-aws aarch64 stuff, circleci only provides arm on machine instances, not docker, huh?
looks like the other builds are docker-based, so there's probably some additional work needed there to setup e.g. localstack
@cap10morgan we could just skip the localstack stuff for that build
ok, great! that's a big help 🙂
maybe setup_remote_docker
could help, run localstack on that?
yeah that's a possibility too
does that work in machine instances? :thinking_face:
i guess so, been a WHILE since ive used it
but looking at the examples maybe not