Fork me on GitHub

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


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


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


If anyone is curious: I've setup a simple testing workflow using github actions and tools-deps:


Couple of notes: - there is java 8 by default, so if you don't need a newer one you can omit actions/[email protected] 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

❤️ 8
💯 4

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


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.


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


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!


👍 also happy to help 🙂


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.


actions/checkout and actions/docker will get build at the start of the workflow, which you can see here:


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


they just happen


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.


of course.


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.


Will do — thanks!


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?


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


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


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.


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


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


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


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

👍 4

Got it, thanks!

👍 4

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


with the v2 actions API


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


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.


this is great though!

😺 4