This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (8)
- # aws (12)
- # babashka (84)
- # beginners (380)
- # calva (56)
- # clj-kondo (52)
- # cljdoc (4)
- # cljs-dev (327)
- # cljsrn (4)
- # clojure (154)
- # clojure-italy (5)
- # clojure-nl (3)
- # clojure-uk (21)
- # clojurescript (52)
- # conjure (133)
- # cursive (64)
- # datomic (33)
- # emacs (22)
- # fulcro (35)
- # graalvm (24)
- # graphql (1)
- # kaocha (1)
- # leiningen (1)
- # off-topic (24)
- # onyx (2)
- # pathom (10)
- # re-frame (3)
- # reagent (3)
- # reitit (3)
- # shadow-cljs (48)
- # spacemacs (12)
- # tools-deps (98)
- # xtdb (7)
Hello, what is a recommended/nice way of organizing a mono-repo like project of multiple tools.deps backed projects in terms of being able to run all tests and produce JARs/docker images/run tests for each from the root of the project? I have something like this, using Makefiles:
. ├── Makefile ├── docker-compose.yaml ├── consumer │ ├── Dockerfile │ ├── Makefile │ ├── deps.edn │ ├── src │ │ └── queue │ │ └── consumer.clj │ └── test │ └── queue │ └── consumer_test.clj └── producer ├── Dockerfile ├── Makefile ├── deps.edn ├── src │ └── queue │ └── producer.clj └── test └── queue └── producer_test.clj
@rahul080327 I'd recommend looking at juxt edge which is my implementation of a monorepo. If you are looking to share makefiles, you probably want the include instruction in make (not shown in edge)
This looks really neat @U09LZR36F! I was considering going the shell approach but was thinking the need for manual orchestration and error handling might be complex hence opted for Make. But will try out your organized approach! Thanks! 😄
Is it possible to use
clj and friends private repositories via a password-protected SSH key?
@ghadi Yes, I did that but I’m getting an error (`USERAUTH fail`) when I try it with a password-protected SSH key.
I don't think it should work
I don't think password protected ssh keys are supported in the set of stuff we're running
JSch, the underlying ssh library, is stupid w.r.t. understanding .ssh/config when there is also an ssh-agent present
% ssh-add -l 4096 SHA256:… /Users/zane/.ssh/id_rsa (RSA)
% cat ~/.ssh/config Host * AddKeysToAgent yes UseKeychain yes IdentityFile ~/.ssh/id_rsa
i.e. It’s using the copy of the repository I downloaded when I was using a passwordless SSH key.
I don't think in your case there is much harm in removing just the IdentityFile portion of that block
or 1 SSH key that grants you access to a bunch of repos, but you also have unrelated SSH keys present too?
Also, I just want to confirm one more thing: https://ask.clojure.org/index.php/8725/deps-support-newer-private-file-formats-types-such-ed25519 that
clj won’t work with OpenSSH-format keys and that you must use
-m PEM when generating them. Is that correct?
My personal recommendation is to not use files at all, only put your ssh keys into the agent
clj can use fancy newer keys like ed25519 keys as long as JSch is asking the agent to deal with them
Right. I certainly wasn’t using SSH with GitHub until I had to get
clj to work with a private repository.
Sorry to barge in on this one but I was searching for answer on how to use the
clj cli (and
:git/url) against github private repos
Did you end up having that working?
Nice, ok I'am going to read up the history then - thank you for confirming!
last q 😄 are Oauth still unsupported?
> The supported git url protocols are https and ssh. https repos will be accessed anonymously and require no additional authentication information. This approach is recommended for public repos. ssh repos may be either public or private.
I know that there were plans to switch
clj over to stop using the JVM implementation of
git, which was the root of all of this pain.
I am quoting the official docs https://clojure.org/reference/deps_and_cli Maybe it did not happen yet? let's ask @ghadi what is the status there :D