Add automated build/deploy on CI

lread commented 2 years ago

Proposal

For consistent builds/releases automate the process on CI

Benefits

Building on a clean CI server reduces risks of any maliciousness sneaking into a jar (not a big worry for Clojure libs, but still)
Ensures a consistent release, for examples:
- scm info in pom.xml will be correct for clojars and cljdoc
- can add checks, for example, does changelog have any description of release?
Avoids human error

Mechanics

I like the slipset strategy which I think borkdude has also adopted.

Here's how it works for graal-build-time:

A new release is cut via a publish task which runs the following locally:

verifies change log looks good
bumps the version (which is stored in its own file)
applies version to change log (we could update README here too if appropriate)
git commits
git tags
git pushes

On CI, for each commit a deploy task is run which

builds the lib jar
attempts to deploys the lib jar to clojars

At first, this seemed rather unrefined to me, as we are attempting a deploy to clojars when we have no intention of really doing so, but this will fail by design when clojars already has version x of our lib.

I love the simplicity of this approach, but still might not be able to avoid the temptation of refining slightly to not attempt a deploy when clojars already has version x of our lib.

Alternatives

For my projects, I initiate a release via a button on a GitHub Actions release flow. I think the slipset/borkdude strategy is maybe simpler (maybe mine is easier?).

Implementation Details

I seem to be using GitHub Actions these days more than CircleCI, but would defer to your preference.

This change would include moving from the deprecated depstar to clojure tools build.

I'd also bring in babashka for build tasks.

phronmophobic commented 2 years ago

This is something I intend to do at some point, but I feel like I only recently got all my projects using the clojure cli, and now it's all deprecated (but works just fine).

As far as tools.build workflows go, it seems like all of the "early" adopters are building their own slightly different, adhoc workflows. Is there a "standard" workflow that I can adopt?

phronmophobic commented 2 years ago

I've been using github actions, so I do prefer github actions over Circle CI.

lread commented 2 years ago

As far as tools.build workflows go, it seems like all of the "early" adopters are building their own slightly different, adhoc workflows. Is there a "standard" workflow that I can adopt?

Yeah I suppose you are right because tools.build is programmatic and not declarative. But the broad brushstrokes around deployment seem to be the same:

a build.clj in the root dir which is has tasks to jar install and deploy
usage of slipset's deps-deploy to deploy to clojars

FWIW, Sean has come up with a convenient wrapper for tools.build but I've not personally seen the need for it yet.

But... usage of tools.build is not mandatory. Could stick with depstar if that's your preference. Personally I don't see any big risk with adopting tools.build now and moving to it might help the community in the unlikely chance that we uncover an issue with it.

And I could lend a hand if that's of interest. But I do totally understand there are some things a project maintainer wants to do tackle themselves.

phronmophobic commented 2 years ago

The wrapper looks pretty straightforward. I'll check it out!

Also, the main issue is that git url is wrong in the pom.xml, right?

phronmophobic commented 2 years ago

I started a branch to fix the pom if that's one of the main issues, https://github.com/phronmophobic/membrane.term/pull/35.

I am still interested in implementing some of the other suggestions you have. It would be nice to have it integrated with CI as well as automatically do some of the bookkeeping you mentioned.

lread commented 2 years ago

Also, the main issue is that git url is wrong in the pom.xml, right?

For cljdoc & clojars? Yup! The scm tag is also wrong.

phronmophobic / membrane.term