circleci 2020-12-24

Hey, I’ve just created a test-project https://github.com/slipset/cautious-engine 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 https://github.com/polymeris/7guis-clojurescript/blob/master/.circleci/config.yml) 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: https://github.com/babashka/babashka-sql-pods/blob/master/script/generate_circleci.clj

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

1
🤩 1

This is ironic in some way, though.