GitHub Action to publish on Clojars?

Is that possible to send package from GitHub? like for npm https://medium.com/faun/automate-your-npm-publish-with-github-actions-dfe8059645dd ?

I would expect this to be possible since lein, boot, and CLI/deps.edn all have ways to build an uberjar and publish it to Clojars. (for the latter, see https://github.com/clojure/tools.deps.alpha/wiki/Tools – I use https://github.com/seancorfield/depstar and https://github.com/slipset/deps-deploy for build/deploy)

Another issue is how to authenticate? npm has tokens for publishing packages. Does Clojars provide tokens as well?

or maybe using password…

$ env CLOJARS_USERNAME=username CLOJARS_PASSWORD=password clj -A:deploy

I use meyvn for deploying by the way.

Turned out Meyvn turned into a closed software in newer version…

root@018f6774f5b1:/bin# clj -Sdeps '{:deps {org.danielsz/meyvn-installer {:mvn/version "1.2.1"}}}' -m meyvn-installer.core
You will need the username/password that came with your licence. Are you ready to proceed? Y(es) or N(o)?
N
Would you like to apply for a licence? Y(es) or N(o)?
N
Bye for now.

I got lots of thing to migrate if deps-deploy is available. But I’m not sure if there’s a cheap way to generate the pom.xml file that deps-deploy. Damn Clojars(maybe it’s maven to blame), I never feel deploying Clojure packages is as simple as deploy npm packages.

depstar helps, I created a lilac.jar file with it. But I still got some confusion, the generated jar file is quite large:

root@6af2038f8c8d:/tmp/lilac/target# du -ah lilac.jar
4.5M	lilac.jar

as I extracted it, I see lots of file under clojure/:

root@6af2038f8c8d:/tmp/lilac/target# jar xvf lilac.jar
  created: lilac/
 inflated: lilac/router.cljs
 inflated: lilac/main.cljs
 inflated: lilac/util.cljs
 inflated: lilac/test.cljs
 inflated: lilac/core.cljs
 inflated: lilac/core.clj
  created: clojure/
  created: clojure/asm/
  created: clojure/asm/commons/
  created: clojure/test/
  created: clojure/instant/
...
root@6af2038f8c8d:/tmp/lilac/target# ls -p
clojure/  lilac/  lilac.jar

Since I’m packaging a ClojureScript package, can I remove them from my jar?

That sounds like you made an uberjar instead of a library jar? You only use uberjar to create applications – for libraries that you deploy to Clojars, you should make a jar instead.

1 Like

It’s true that clj -Spom will only get you part of the way. It’s why clj-new now produces fully-fleshed out pom.xml files in new app, lib, and template projects. See GitHub - seancorfield/clj-new: Generate new projects based on clj, Boot, or Leiningen Templates! onward for a discussion of that.

1 Like

Turned to depstar.jar and it worked.

I ran into another issue that when my package finally loaded into shadow-cljs and it told me lilac/core.clj was not find:

[:client] Configuring build.
[:server] Configuring build.
[:server] Compiling ...
[:client] Compiling ...
[:server] Build failure:
------ ERROR -------------------------------------------------------------------
 File: jar:file:/Users/chen/.m2/repository/mvc-works/lilac/0.1.0-dev2/lilac-0.1.0-dev2.jar!/lilac/core.cljs
failed to require macro-ns "lilac.core", it was required by "lilac.core"
FileNotFoundException: Could not locate lilac/core__init.class, lilac/core.clj or lilac/core.cljc on classpath.
	clojure.lang.RT.load (RT.java:462)
	clojure.lang.RT.load (RT.java:424)
	clojure.core/load/fn--6839 (core.clj:6126)
	clojure.core/load (core.clj:6125)
	clojure.core/load (core.clj:6109)
	clojure.core/load-one (core.clj:5908)
	clojure.core/load-one (core.clj:5903)
	clojure.core/load-lib/fn--6780 (core.clj:5948)
	clojure.core/load-lib (core.clj:5947)
	clojure.core/load-lib (core.clj:5928)
	clojure.core/apply (core.clj:667)
	clojure.core/load-libs (core.clj:5985)
	clojure.core/load-libs (core.clj:5969)

I went to ~/.m2/ and find the package of the specific version, the file lilac/core.clj existed:

=>> c 0.1.0-dev2/
_remote.repositories  lilac-0.1.0-dev2.jar  lilac-0.1.0-dev2.pom
=>> jar xvf lilac-0.1.0-dev2.jar
  created: lilac/
 inflated: lilac/main.cljs
 inflated: lilac/test.cljs
 inflated: lilac/router.cljs
 inflated: lilac/util.cljs
 inflated: lilac/core.cljs
 inflated: lilac/core.clj
  created: META-INF/
 inflated: META-INF/MANIFEST.MF
  created: META-INF/maven/
  created: META-INF/maven/mvc-works/
  created: META-INF/maven/mvc-works/lilac/
 inflated: META-INF/maven/mvc-works/lilac/pom.properties
 inflated: META-INF/maven/mvc-works/lilac/pom.xml

In my original project https://github.com/mvc-works/lilac/tree/deps-deploy I have two folders src/ and macros/, and lilac/core.clj locates in macros/ folder. Pretty confused if that would cause problems.


Updates:

I reran shadow-cljs but the error is missing… now I’m bit confused…

I’m not quite sure what the behavior should be (for cljs) when you have both file.cljs and file.clj. Someone familiar with ClojureScript and macros will hopefully be able to answer that.

At least it’s working for now. The package got deployed https://github.com/mvc-works/lilac/runs/436699319?check_suite_focus=true .

Thanks for the help.

I just published a small lib intended to streamline the common release flow for small libraries that use tools.deps: https://github.com/appliedsciencestudio/deps-library

The motivating use case is publishing versioned releases of small & simple libraries without having to have to configure three different tools every time.

It’s just one day old, & open to feedback.

4 Likes

Looks cool? It looks like the version is related to git tags. But how do you decide the versions from tags? And would it work properly if that runs in CI environments?

Also a more general question… I’m quite wondering why group-id and artifact-id are not inside deps.edn, like package.json in Node.js . Package management being a core feature of the whole ecosystem seems not being enhanced enough.

1 Like

Versioning is managed by garamond, which bumps the tag (looked up from previous tags in git) based on the increment you pass (patch, minor, or major).

It works well with CI - I use it for js-interop and have a workflow triggered when I push a new tag: https://github.com/appliedsciencestudio/js-interop/blob/master/.circleci/config.yml#L63. (Requires git push --follow-tags)

I’m not familiar with accepted practices or recommendations for adding new keys to deps.edn. Is that a thing? I’m not convinced the release.edn approach is best, but it seemed like a reasonable place to start.

1 Like

Personally I prefer specifying a version by myself, since I have to create PRs and I need tags like 0.1.1-a1 before it’s being merged.

I’ve just released 0.2.0 with support for passing a -v or --version flag to tag/release an arbitrary version. Eg/

clj -A:release -v 0.1.1-alpha.1 

there is also a --dry-run flag which will tell you what’s going to happen (eg. when passing --patch) without performing any side effects.

1 Like

Managed to publish my package to clojars. Super smooth compared to other solutions.(Meyvn used to such easy too very long time ago…).

I’m still feeling quite rough to have version in CLI. Is there are reason why it can’t be in reease.edn?

1 Like

great to hear!

I’ve just released 0.3.0:

  • lets you specify a :version in release.edn
  • All options also be passed as command line args, so the release.edn file is optional.

Documentation in the readme: deps-library/README.md at master · applied-science/deps-library · GitHub

1 Like

thanks :star_struck:

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.