Skill Publish Readiness Checks for lein-m2-deploy-skill

[slimslenderslacks]

We believe, based on input from clojurians slack, that we can get some engagement on a public skill for deploying signed jars to clojars, whenever a Tag is pushed to a Repo containing a project.clj file. The skill will also offer a set of configurable github checks to gate the deployment. The Skill will also add a Check when deployments are made in order to advertise Atomist to users in public Repos.

The benefit to the User is that all of their current and future clojure projects standardize around:

• publish OnTag
• only publish libraries passing checks
• all jars are signed with the same identity
• clojars deployment creds in one place
• all project.clj files verified to have standard deployment configuration

Skill Work left to do

• [x] signing key configuration - we believe that we should NOT provide an option to deploy unsigned jars. We should take advantage of how hard it is to configure signing to make the point that skills consolidate difficult configuration in one place
• [ ] input of Clojars secret to the Secret Provider - Ideally, our UI would support easy addition of clojars secret at skill configuration time
• [ ] skill -> skill dependencies in the UI. This skill relies on the Content Indexing Skill. What we actually want to do is add a rule to a configured content indexing skill if this skill is configured.

[slimslenderslacks]

@kipz I made some more notes in the project README: https://github.com/atomist-skills/lein-m2-deploy-skill

I did a lot of experimenting with different signing procedures both in leiningen and in deps.edn today.

[slimslenderslacks]

• [x] this only supports patch versioning today.
  If we respond to tags instead, we can put versioning back into the hands of the developer.
• [x] we should document that we don't care what version is in the checked in project.clj (which is a best practice in our opinion)
• [x] we should probably mention that this skill does not deploy snapshots, and will therefore never use the snapshots repository. This is release only (also a best practice).
• [x] we should also document the leiningen convention of configuring a releases repo in either :repositories or :deploy-repositories.
  Leiningen documentation talks a lot about how to add credentials here but the beauty of this skill is that we can inject the credentials from one place. However, it seems to me we should also automatically update the project.clj to use our convention before running. Why would leave a potential inconsistency between project.clj and skill config if we can check it?
• [x] leiningen supports a strange property named :deploy-branches, which could breaks this skill if the local project.clj has this property and the default branch is not included in it
• [x] this skill will fail if the project.clj does not have a :license, :description and :url We should make this error more explicit.
• [x] leiningen also supports https proxies here but Skill users should not need these unless we're trying to publish to a private registry accessibly only through a proxy. We probably want to ignore proxy settings added by developers that are behind a proxy, and where the skill does not have the same restriction.
• [x] whether or not we sign is determined by the :sign-releases option in the repository opts map. Should we always set this to false?
• [x] the :gpg-key and :passphrase are the only real signing options, and supporting these would require that we address whether or not we're will to manage an identity for the skill configurer. See below.

[slimslenderslacks]

I've added a note that we are blocked by not being able to support clojars deployments right now.

[atomist[bot]]

Thanks for your contribution!

This issue has been automatically marked with stale because it has not had any activity in last 50 days. It will be closed in 7 days if no further activity occurs. To prevent closing, label with defer or blocked or any of the changelog: labels.