This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-09-13
Channels
- # announcements (2)
- # babashka (2)
- # beginners (112)
- # calva (29)
- # cider (33)
- # clj-kondo (41)
- # cljdoc (10)
- # cljs-dev (2)
- # clojure (72)
- # clojure-berlin (3)
- # clojure-europe (10)
- # clojure-italy (6)
- # clojure-nl (15)
- # clojure-spec (5)
- # clojure-uk (40)
- # clojurescript (1)
- # clr (6)
- # community-development (6)
- # core-async (21)
- # cursive (42)
- # datascript (12)
- # duct (6)
- # flambo (1)
- # fulcro (50)
- # jobs (1)
- # leiningen (3)
- # off-topic (16)
- # re-frame (6)
- # reagent (23)
- # reitit (7)
- # ring-swagger (14)
- # shadow-cljs (35)
- # tools-deps (39)
- # vim (12)
I'm having some trouble using a jar from a private Maven repo (we're using Gitlab's built-in maven repos)
I can install it fine with Maven, and see it in ~/.m2
, but when I do clj
it seems it still tries to fetch it, Error building classpath. Could not find artifact group:artifact:jar:version in central (
If anyone is curious: I've setup a simple testing workflow using github actions and tools-deps: https://github.com/cljfx/cljfx/blob/master/.github/workflows/test.yml
Couple of notes:
- there is java 8 by default, so if you don't need a newer one you can omit actions/setup-java@v1
action
- use clojure
instead of clj
, duh
I also want to say again how much I love tools-deps. Aliases and their simplicity is amazing: adding workflow-specific aliases is such a breeze, and mixing them in different contexts is very straightforward. Thank you very much cognitect and @alexmiller
I have :test
alias to add test
directory and test-specific deps, I have :runner
alias to run tests, I have :headless
alias to run cljfx without display. During dev I have :test
alias on, I can run tests locally with -A:test:runner
, and I can make CI run tests in headless mode with -A:test:runner:headless
. So simple
hey! as someone doing a lot with github actions too, this is great. I might recommend using some more Docker-based actions rather than shell-based ones, which might make things a little bit faster.
Totally understandable Vlad, but if and when you do want to give it a try, I think GitHub has done a good job making this super simple. Basically you just add a container
key to your job definition and Actions takes care of getting the image, starting a container, and then running your job’s steps within that container.
So for example you could add container: clojure:tools-deps
to your job definition and then in your steps you wouldn’t need to set up Java nor install Clojure. Presumably this would become faster over time as GitHub does a better job of caching docker image layers. And there are a bunch of variants of the clojure
image, e.g. with different OS’s, different JREs, etc.
HTH but feel free to ignore if it’s not the right time!
it'll even build a repo from a Dockerfile, which adds time but is great for development
Ooo really? I didn’t know that — that’s excellent! I gotta look up the docs on that. Thanks!
of course. if you use actions/checkout and actions/docker, it's all Dockerfile based so there's pre-steps to build those images.
i'd like to optimize that, but here's an example workflow: https://github.com/kudobuilder/kudo/blob/master/.github/workflows/release-on-master.yml
actions/checkout and actions/docker will get build at the start of the workflow, which you can see here: https://github.com/kudobuilder/kudo/commit/7ee65861db6b426e87618bd44b94b469a0e99802/checks
Aha, that makes sense! It’s kinda naturally intuitive once I unlearn the constraints I learned from CircleCI, wherein for a given job I have to choose between a VM and a container, so there’s no concise way to build an image and then use it.
i'm also well integrated with the actions team and the implementation since we're doing a lot kubernetes-wise with this, so if you need any help or support, let me know and I can either help or point you at the right people within github.
Hey, many thanks for the info! I have a question: what problem does docker solve that actions don't? You mentioned that you can have different docker images with different OSs, JREs — isn't it something already solved by actions matrix?
I’m not sure about actions matrix; I haven’t looked closely at it yet. As for using docker in general, it can sometimes make jobs more concise and sometimes, theoretically, faster, because the images might be cached.
It can also make it easier to debug/troubleshoot issues in a CI job because you can then use the same exact environment locally to reproduce the situation
and you can think of an action as an individual step (but reproducible as a lego block) in a whole workflow