fn-fx / fn-fx

A Functional API around JavaFX / OpenJFX.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Setup automatic deployment of snapshots to Clojars from master branch

pmonks opened this issue · comments

Also blocked on technomancy/leiningen#2473 😞

Having automated deployment of two "editions" of the library (one for JavaFX and one for OpenJFX) is looking increasingly complicated, and in the interest of momentum I'm tempted to just kick this can down the road so we can at least get some level of automated builds up and running.

Given that the code is (for now) identical on JavaFX and OpenJFX, and the only difference is in the library's dependencies, I'm going to update the build scripts such that a single edition of the library is deployed to Clojars, and the docs say something like "if you're targeting a version of the JVM that doesn't bundle JavaFX, you will also need to express the following dependencies: ...[OpenJFX dependencies]...".

I'm the first to admit that this is a pretty lame developer experience for consumers of the library, but at least it's a one-time copy & paste exercise, and at least we'll have automated deployments coming out of master in the mean time.

I don't know how the deployment works, but I just saw the clojars credentials in the code, and it occured to me that it might not be safe. Can someone push a version to clojars from another repo if he or she has the credentials?

TravisCI's encryption mechanism is described here, but in a nutshell those encrypted values can only be decrypted by TravisCI, and only for this one project (fn-fx).

So yes this is safe (well, as safe as the encryption mechanism TravisCI uses...), and gives us the benefit of automatic deployment (CI and CD); any time anyone merges a PR to master, that change will be built and deployed to Clojars automatically*.

*there's one exception to this: Clojars requires signing of non-SNAPSHOT builds, and I'm (obviously!) reluctant to give TravisCI my private key for that purpose. We can either disable JAR signing for releases (which I don't like very much) or just build releases manually and not have TravisCI generate them.

BTW I worked with a kick-ass devops guy (@maoo) who taught me all this stuff. He showed me the productivity benefits of fully automated end to end CD, all the way from dev to production, and I'm now a huge fan of this style of development. 😉

👍

*there's one exception to this: Clojars requires signing of non-SNAPSHOT builds, and I'm (obviously!) reluctant to give TravisCI my private key for that purpose. We can either disable JAR signing for releases (which I don't like very much) or just build releases manually and not have TravisCI generate them.

I think it's fine to have manual releases. Not everything in the world should be automatic. :)