This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-05-29
Channels
- # aleph (1)
- # announcements (10)
- # aws (1)
- # beginners (110)
- # calva (4)
- # cider (26)
- # clj-kondo (14)
- # cljdoc (24)
- # cljsrn (16)
- # clojure (76)
- # clojure-europe (3)
- # clojure-ireland (2)
- # clojure-italy (15)
- # clojure-nl (8)
- # clojure-spec (23)
- # clojure-sweden (4)
- # clojure-uk (92)
- # clojurescript (37)
- # cursive (19)
- # datomic (59)
- # duct (1)
- # emacs (4)
- # fulcro (7)
- # graalvm (7)
- # graphql (1)
- # hoplon (69)
- # jobs (4)
- # jobs-rus (1)
- # kaocha (2)
- # leiningen (5)
- # luminus (2)
- # pathom (8)
- # reagent (6)
- # reitit (11)
- # spacemacs (12)
- # sql (3)
- # tools-deps (9)
- # unrepl (1)
- # vim (57)
Is there anything I can do to debug a failed build (this one: https://cljdoc.org/d/trident/trident/0.1.1-1-SNAPSHOT)? if not, could someone look into it for me?
It failed with exception-during-import
. It works with cljdoc running locally, and the git repository is linked correctly (see https://clojars.org/trident/versions/0.1.1-1-SNAPSHOT), so I'm not sure what else to try.
@foo I think it's because the tag in your pom.xml has no matching release on GitHub?
If you go to Clojars, and click the commit
link (right hand side), you get a Not Found page -- because that tag doesn't exist in the repo.
(and that's true for every release you've deployed to Clojars)
The <tag>
in the pom.xml
file needs to be an identifiable commit in the repo so cljdoc can clone it and analyze it.
ah, I see. I think I made a wrong assumption when I set the tag and forgot to verify it. thanks!
@foo I think what @seancorfield is saying is correct. The easiest way to check if things work locally is ./script/cljdoc ingest -p trident -v 0.1.1-1-SNAPSHOT
— I assume you might have passed --rev
argument to that in which case the issue with pom.xml
<tag>
wouldn't surface?
I didn't pass --rev
but I did pass --git
. It didn't occur to me to try omitting that, but yeah, leaving it out reproduces the error :thumbsup: thanks
Thats weird though, if you could open an issue with repro steps that might be helpful, could be a bug. Any investigation on your end also welcome of course :)
The root problem was that I wasn't aware git push
doesn't also push tags; after I did git push origin 0.1.1-1-SNAPSHOT
it worked (at least it worked locally, I'll try pushing to clojars again in a sec)
Is ingesting supposed to work even if <tag>
is incorrectly specified in pom.xml
?
I mean, I guess ideally even if the git import stuff broke, ingesting would go ahead and at least import the docstrings from the jar. idk if that's worth doing or not, it's also not a bad idea for people like me to just fix the git import 😉
@foo If it's any consolation, my first half dozen attempts to publish to Clojars and get cljdoc to ingest it all correctly, using deps.edn
and a generated pom.xml
, were all unsuccessful -- it took me a while to get my pom.xml
right.
If you have any takeaways that could be documented... 😉
My takeaway was that I needed to learn to read the docs better! The docs said exactly what needed to be in my pom.xml
but I thought I could use different values/formats instead (because I didn't know enough about Maven/`pom.xml`/how Clojars worked).
:thumbsup: I'll do a little retrospective once I've confirmed it's all actually working and possibly open a PR for cljdoc's documentation
My takeaway was that I needed to learn to read the docs better! The docs said exactly what needed to be in my pom.xml
but I thought I could use different values/formats instead (because I didn't know enough about Maven/`pom.xml`/how Clojars worked).
Got it. Well I guess there still is something we could take away from this. Probably some visual changes would help. Maybe it’s formatting or using asciidoc info/warn blocks.
haha yeah that was a takeaway for me too, specifically the docs show a commit hash as the value of <tag>
, but later on when I was actually doing it, I used the git tag instead.
Rather than trying to tweak the docs, more specific error messages could be better. e.g. in my case, instead of just exception-during-import
, maybe say something like Couldn't find commit hash 0.1.1-1-SNAPSHOT at repo
Also I think I'm reeally close now... but it looks like the analysis isn't including the datomic repo (https://circleci.com/gh/cljdoc/builder/5606)
...
:repos
{"clojars" {:url " "},
"central" {:url " "}}}
...
Failed to read artifact descriptor for com.datomic:ion:jar:0.9.28
...
Even though I have this in my pom.xml:
<repositories>
<repository>
<id>datomic-cloud</id>
<url>s3://datomic-releases-1fc2183a/maven/releases</url>
</repository>
<repository>
<id>clojars</id>
<url>https://repo.clojars.org/</url>
</repository>
<repository>
<id>maven</id>
<url>https://repo1.maven.org/maven2</url>
</repository>
</repositories>
Could it be an issue with the s3://
protocol in the datomic repo? maybe cljdoc only works with http?it works locally, presumably because I have the artifact in my .m2
directory already
I think that might be an issue with tools deps which is used to resolve dependencies.
As for error messages, there is an open issue to surface more low level error causes instead of just “exception-during-import”
https://github.com/cljdoc/cljdoc/issues/111 - happy to guide anyone through their first contribution to make this happen :)
I should be able to take a stab at it sometime. Also I had forgotton that you need aws credentials set up to use the datomic repo, so that must be the cause of my current problem.