Clojurians Log v2

@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 think we dont have any alpine images since 0.7.2 😞

hi!

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

cool thank you!

@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

ah I see!

@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

had a failure with the buildx setup too, rerunning fixed it, trying it now

ok

https://hub.docker.com/layers/moby/buildkit/buildx-stable-1/images/sha256-905307ef07e366e5977163218b9f01e9553fe2c15fe5e4a529328f91b510351d?context=explore

thank you guys!

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?

yes

cool

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

hmm

that's not how we did it before

the unqualified version always refers to the latest stable version

so I would not change that!

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

we did push snapshots, but under the snapshot tag or so, let me check

alpine is basically latest for alpine

yes checked now they have a SNAPSHOT in the tag

all of that coming shortly

yes, we pushed to 0.7.3-SNAPSHOT etc

https://hub.docker.com/layers/babashka/babashka/0.7.4-SNAPSHOT/images/sha256-2392370693900d38b805a262114f8998377e3923ed82de403abc16bc636d5a23?context=explore

@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

no hurries! having the alpine images unblocked is first one!

would you open another PR?

yep, once I remember how when GH isn't suggesting it 🤣

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. facepalm yeah, you're right, it needs the full command again.

isn't 100% in love with buildx

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

but this is better now

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 🤔 dunno my head spins at these build layer caching nowadays

ok, build finished it seems

do the snapshot images look ok now?

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? 🤔

i guess so, been a WHILE since ive used it

but looking at the examples maybe not

just skip it, make the aarch64 compilation work and be done with it

there's perhaps one or two calls that don't need AWS, e.g. for fetching the available AWS things it can do, we could just test that as a smoke test