Transfer initiated! 🙂

Mail received 🙂

I guess we should get a first clj-commons release of clj-http-lite. @borkdude are you ok if I do that?

sure

I might want to change from github-actions to circle to do the ci/cd stuff as well

I’ll look into that tomorrow then.

as a fan of circle I'm not opposed to that

Did you see @ingesol made a “port” of my build stuff to deps.edn based builds?

I haven't

https://github.com/ingesolvoll/re-statecharts/blob/main/build.clj

There is some more to this, but basically he has the whole “deploy-to-clojars-by-pushing-a-tag” going for that project.

yeah, makes sense

I have several of my projects auto-deploying SNAPSHOT builds to Clojars on every successful main branch CI run (via GH actions). I've been toying with the idea of automating releases but I'm still a bit paranoid about that last step 🙂

@seancorfield I have automated releases with automatic uploading of artifacts (even from different build environments to one release: Circle, Appveyor) but it puts the release in draft. Then when every process has uploaded its thing, I publish it from draft to public.

This is my personal lib I use in several builds: https://github.com/borkdude/gh-release-artifact

Oh you mean, non-SNAPSHOT releases? Why would you think it's safer to do this from your own machine rather than from CI?

I would think the reverse. It happened to me more than once that I compiled some Java sources using JVM 11 and someone on 8 couldn't use it.

I don't have to worry about Java or AOT but I guess I still view non-snapshot releases as "Important(™)" and so they should be deliberate and not quite as automated. But I could add a manual GH action for it since the only difference is whether I specify :snapshot true for my build action or not...

Y'all convinced me. next.jdbc 1.2.753 was an automated release to Clojars from GH Actions. Thank you for the "push". I'll update other repos as I get close to releases...