Fork me on GitHub
#tools-deps
<
2019-09-13
>
plexus15:09:22

I'm having some trouble using a jar from a private Maven repo (we're using Gitlab's built-in maven repos)

plexus15:09:19

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 ()

plexus15:09:40

is this to be expected, or am I holding it wrong?

dominicm15:09:52

I think it will try there, but it should also try from your repo that's configured

vlaaad20:09:47

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

vlaaad20:09:00

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

vlaaad20:09:43

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

❤️ 8
💯 4
vlaaad20:09:54

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 clj

gerred20:09:09

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.

vlaaad20:09:33

But then I'd need to figure out docker in addition to github actions, I'm too lazy 😛

avi15:09:02

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!

gerred15:09:17

👍 also happy to help 🙂

gerred15:09:41

it'll even build a repo from a Dockerfile, which adds time but is great for development

avi15:09:12

Ooo really? I didn’t know that — that’s excellent! I gotta look up the docs on that. Thanks!

gerred15:09:41

of course. if you use actions/checkout and actions/docker, it's all Dockerfile based so there's pre-steps to build those images.

gerred15:09:35

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

gerred15:09:42

"Build x..." aren't steps in our workflow

gerred15:09:47

they just happen

avi15:09:27

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.

gerred15:09:33

of course.

gerred15:09:38

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.

avi15:09:48

Will do — thanks!

vlaaad15:09:25

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?

gerred15:09:44

actions in-and-of-themselves are either based on Docker or javascript.

gerred15:09:53

workflows are made up of a series of actions, which build up matrices, etc.

avi15:09:07

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.

gerred15:09:28

you can also technically just run shell commands on the host runs-on I guess.

gerred15:09:36

brb, doing a CNCF TOC presentation, I'll be back in a bit.

avi15:09:45

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

vlaaad15:09:03

Ah, you mean if I have docker setup at local machine

👍 4
vlaaad15:09:33

Got it, thanks!

👍 4
gerred15:09:51

and you can think of an action as an individual step (but reproducible as a lego block) in a whole workflow

gerred15:09:54

with the v2 actions API

gerred20:09:31

(I have a clj-kondo action currently in progress as well)

vlaaad20:09:41

What I'd really like to have is a tools-deps action, with .m2 and .gitlibs caching etc. Configurable by aliases and deps.edn in a project.

gerred20:09:13

this is great though!

😺 4
4