missed out the damned =~ in the shell code 😞
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 ;)
yeah
> def snapshot? i was following the recommendation of adding a ? only in preds
I think it's clearer that way
cool
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
right
if you see https://circleci.com/api/v1.1/project/github/babashka/babashka/28238/output/106/0?file=true&allocation-id=62589614992d06610392c011-0-build%2FG2BIUGKC it is pushing all the relevant images. Search for Building and pushing
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
docker hub looks okay i think: https://hub.docker.com/r/babashka/babashka/tags
agreed
should be good now
hmm, clj-kondo should have caught that? https://github.com/babashka/babashka/commit/546ddbeae6b68d9b6c1dcd62751990b2379a1d02
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
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
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
Anyway :)
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
yes
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?
aha
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 😛
I posted it here: https://www.reddit.com/r/Clojure/comments/u49yqj/novalug_talk_babashka_and_clojure/
The video is a bit blurry but hopefully youtube is rendering it still for higher quality or so
awesome! thanks a lot!
@cap10morgan for your context, this was the issue: https://clojurians.slack.com/archives/CLX41ASCS/p1650020392797919
@rahul080327 @cap10morgan I'm doing a 0.8.1 release now, let's pay attention to dockerhub
in 10 minutes or so
on it
thats a weird failure
you mean the JVM? it happens sometimes, don't know why
yeah
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
yeah
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=0x4f7946I 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?
don't know
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
right
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 🙏🏼
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): DONEin 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 😛
you too :)
i guess adding :throw true to the calls here https://github.com/borkdude/gh-release-artifact/blob/main/src/borkdude/gh_release_artifact.clj#L177 could help a bit maybe?
im guess one or more of them had some 400+ status
yeah maybe