babashka-sci-dev 2022-04-15

missed out the damned =~ in the shell code 😞

❤️ 1
🚀 1

at least we can blame bash again with their weird syntax!

also for only having the arm ones and not amd, tested the env parsing bit locally, not sure was that related to this too?

[clojure.string :as s] , can we use :as str ?

well, before that everything still worked, so I think it was related to this PR?

(def snapshot? (str/includes? image-tag "SNAPSHOT"))
(question mark + alias)

> can we use :as str ? i can, just the the colouring gets a bit weird for me as it thinks its the core/str

i can do full string?

that's a problem of your tool, not of how people usually write clojure ;)

> def snapshot? i was following the recommendation of adding a ? only in preds

I think it's clearer that way

I've tried implementing a linter for the ? behavior but it's impossible, people use it in too many different ways

e.g also in keywords/destructuring, while they're not predicates, I gave up enforcing anything around that

makes sense, i too never understood the consistency of ! and ?

I think the PR looks good now aside from those minor things. But how can we test if the arches are correct now since they weren't last time? Was the problem that the :latest image was now arm64 instead of amd64?

Maybe add some debug printlns in there so we can follow more closely what it's doing?

and then enable in your PR branch so we can test before merge

yeah, but it gets lost in the buildx noise, what im trying to do is run this locally with some prints and the same env vars

will add the prints too

Ah, the original bash script checked if we were on master, but this script doesn't?

thats the check we are enforcing from circle yaml anyways right?

i thought thats redundant

I think we should leave it in. Make minimal changes to the logic while porting

stay as close as possible to the original

this is the log when its merged to master

Maybe amd64 latest was overwritten with arm64 latest?

ah could be, and now if i put in the same checks as the shell, it wont run, will put it back along with the circle yaml

yes i see the issue, the --platform in buildx is the whole comma separated string not each one

the naming of the vars confused me

the split is there only to make the folders

and its not in the loop, my head hurts

maybe the problem is that you think too much, just stay as close to the bash script as possible and don't think? :)

that's what I've basically done with deps.clj too when porting the clojure bash script :P

yeah its me more misreading the $p and $platform and the loops i think

issue was $platform can both have one or more things

maybe it should be renamed to platforms?

yeah thats what i was trying the clojure side and messed up the loops

i can rename the env var too if this works fine now

Why is there is a replacement of / to - in the platform names? Why aren't they - in the first place?

docker wants os/arch, tarballs need os-arch. that's all.

Just a question, not a request for change

my undesrstanding is that / is generally the way to specify it and we use - in the tar gz files

we could keep it to -

the / also aids a bit in putting the bins in the correct place and thats how the http://dockerfile.ci picks it up but all that can be changed to - too

it's fine, let's not change too much

yeah its mostly driven by the docker convention of / and mapping it to the names we are using in the releases

ok, all set for merge now?

adding the guards back

should be good now

yeah my lsp inst triggering well

probably wrong project root or something

ok, let's ask @cap10morgan if he wants to glance over this PR as well https://github.com/babashka/babashka/pull/1243

👀 1

after that, we merge

yeah more people looking at it, the better

thanks a lot for the extra work

no worries, sorry for the bumps

❤️ 1

any ideas when your talk is going to be out on video?

well should be in https://novalug.org/presentations.html but yeah will drop them a mail about it

don't mean to push them ;)

yeah just a normal "we are excited to see it" mail 😛

ah so if i add {:source-paths ["src" "test" ".circleci/script"]} to .lsp/config.edn the much needed linting and others work

should this be checked in maybe?

dunno, for me it always works

regardless of source paths

maybe its via flycheck not lsp?

could be, but also navigation works for me on any script, even outside of source-paths

yeah i can do that too, just that the linting bit doesnt work somehow 🤔

i just have lsp, no dedicated kondo

I use linting separately from clojure-lsp so that could be it

but if nav works then why doesn't linting work, maybe ask in #lsp

nav depends on clj-kondo analysis

yeah i'll find a minimal repro

Unintended effect of re-running 0.8.0 release :/ https://github.com/babashka/babashka/issues/1244

I wouldn't be surprised if other package managers will also be affected by this

yeah, more reminders for the amount of side effects 😕

cant believe its all down to me not noticing the extra ~ in the =

Arguably this is one of the most dangerous scripts to mess with, but now you've nailed it, the compile script should be far less error prone, as the test suite still comes after that

don't know what other bash shit we have left

the uberjar script is quite a monster too, I'll probably rewrite that to tools.build some day

(we have uberjar + uberjar.bat, both a are pain)

yeah dont think that can be bootstrapped with a bb jar i suppose

compile yes

if it can be moved to tools.build would be nicely cross platform too i hope

also can get rid of lein completely then

but I'll probably save that for a rainy Sunday

or a boring train trip or so

yeah im just more interested in purging the shell things

bb src itself is the reason bb was built.

bourne again bb

would tools.build work well on windows? i could maybe take a crack at making compile+uberjar to that?

We only need tools.build for the uberjar. The compile step should be separate.

The reason to migrate would be the feature flag stuff which leads to complex shell scripts, but with tools.build this would be easy

I guess the vid is still being rendered or so by youtube

yeah, all of the intro to the talk is foreshadowing of the fuck ups i did yesterday 😛

🔥 1

The video is a bit blurry but hopefully youtube is rendering it still for higher quality or so

awesome! thanks a lot!

docker hub looks good to me @borkdude @cap10morgan

🎉 1

@rahul080327 @cap10morgan I'm doing a 0.8.1 release now, let's pay attention to dockerhub

in 10 minutes or so

thats a weird failure

you mean the JVM? it happens sometimes, don't know why

I will re-run from failure

when the others are done

it happens especially when you want to release

i guess we need to update to the cimg circleci images sometime, that deprecation warning we are getting

yeah as well

well the docker should go through with the failure

why does it take 2 minutes to push binaries we already have to docker hub again?

docker job successful, can you check docker hub?

hub looks good

all the arches look okay

> why does it take 2 minutes to push binaries we already have to docker hub again? its building it all over again, so i guess different hashes

Some golang leaking through in the test output :P

Ran 197 tests containing 580 assertions.
0 failures, 0 errors.
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x4f7946

I guess we don't shut down the pod very nicely

interesting

maybe in the pods library there is a missing shutdown hook or so

we dont have a handler for the exit is it?

this only happens on the jvm side so it might be in the jvm side of the pods lib

right will check the go ones we have, if we all have a shutdown handler there too

in sqlite's pod we might want to implement the shutdown op

if we don't have that

yeah looks like its the sqlite one

but then bb just sends a kill to the pod right? not sure why theres a segfault

for some reason the linux static binary wasn't uploaded.

awesome 🙏🏼

ah missed it

Uploading /tmp/release to release
Uploading /tmp/release/babashka-0.8.1-linux-amd64-static.tar.gz (23 MB): DONE
Uploading /tmp/release/linux-amd64-static-metabom.jar (35 kB): DONE

in the logs it said it did

I'll do that manually. what a fucking joke this automation is ;)

well this part of the script im yet to explore

which one is it again?

well the tar was there and says its done, then what did it miss?

some github api gaff?

yeah think so

same weirdness in the jvm step

similar API call

anyway, 0.8.1 is now released, we can call it a day ;)

finally. happy easter 😛

im guess one or more of them had some 400+ status