Fork me on GitHub

Hey, I’ve just created a test-project to play with automated build/deployment to clojars for Clojure projects. I plan on using something like this for all clj-commons projects (so that I don’t have to build stuff on my machine).


The config.yml looks good to me. If you wanted you could DRY it a little bit by using aliases, executors and/or commands (example Or put the common stuff in an orb, as you say.


And using [ci deploy] as a marker to deploy should work, but I think it's more common to use a branch or tag.


I would really appreciate feedback from you Circle people on how this could be improved.


I still see a missing piece, which is setting this up to sign the artifacts with gpg.


A couple of goals: 1. I do not want circle to do commits back to the repository it’s building for 2. I want versions to be on the form x.y.commit-number 3. I want as little as possible to do with yaml, in particular, now I have two workflows, which seems too much to me, but I wanted to run this thing with a context so I could get my env-var set.


I would be duplicating all or parts of this across mulitple projects (with some variations jdk-versions and lein vs deps.edn come to mind), so it would be nice to have something (maybe an orb, I know nothing about orbs) to deal with the common stuff?


@slipset I'm generating the circelci yaml for different parameters here from clojure/babashka:


The use case there is that I need a couple of similar flows with similar jobs but the binary name and OS are different between them


The benefit of this approach is that you don't need to know a DSL of CircleCI (or Github actions) but you can just generate it using simple primitives

nice 3

This is ironic in some way, though.