Clojurians Log v2

that would probably be a good idea

Yeah, but these sequences often start with something so "simple" you're like "heh, easy... I'll just commit this one small change to the main branch!"

I've done this often and been cursing "easy" so bad when I'm five or six deep, thinking "I shoulda made a branch!" 😄

My impression is that Adrian was setting up his CI for the first time but I may be mistaken.

When I iterate post-initial-setup I do what you describe Sean, but in the trunk based dev case, I try to make the guts of CI portable enough that I can do a local check before a main commit.

I have had my best results with running CI on branches before merging to main

but being able to run as much as possible locally is good too

Actually, that begs an interesting and useful question: how do you test a GH Actions workflow locally? For example, I mostly have my default branch be develop in repos, and when I set up rephrase, I forgot and left main as the default -- and copied in the various GHA .yml files from another project, edited them to match rephrase... and then of course it did nothing when I pushed it because I wasn't on the develop branch. How would you test/detect that?

my primary experience is with jenkins, where we could pick an arbitrary artifact to run through CI, which could come from any branch

with an automated run for all merges to the primary branch

(I will say that since I switched to bb tasks for most of my projects' builds, my CI setup has gotten a lot easier to get right!)

One of the reasons I'm making my own CI... server system? Package? Uberscript that replaces everything else? Don't know how to name it... ... but yeah, I love the idea of CIs, but I hate the implementation of it.

I can test some things locally, but in this case it was building a native library for macosx and linux. For some reason, I use macports, but the CI system uses homebrew. I could try to setup a linux system to try and test things before CI, but it's not quite complicated enough to make that worth the effort in this particular case.

Also, I often use CI to make sure that my builds aren't coupled to my particular setup so my CI usage is often even more prone than usual to run into problems I can't test locally.

One funny AI paradox is the more you prompt, prompt, prompt without reading the code the less specific you are with the prompt in terms of files and lines of code. the more the AI has to go on a haitus to look for what you mean. the more you burn tokens. and the more you waste water. and the more anthropic makes money.

So, it seems the job market is bouncing back, is it? https://x.com/DavidSacks/status/2058606722110107970

For some CI cases nix really shines here. You can cross compile just like the CI can. And in fact because the builds are hermetic you're basically guaranteed that if it works locally it'll work in CI (because the environments are identical). Of course that's for building software. If you're touching external systems than a nix build won't help you.

I see a lot of people posting about problems getting Clojure projects running properly on nix so it seems like you're trading one set of problems for another...

Sean I just use multiple -T alias in deps, and while each one is separate in GHA, I just have a small aggregator script for a local run.

@lambeauxworks That's similar to what I used to do before i switched to bb. Now my CI is bb ci for matrix testing (across JDKs -- the ci task already does multi-version Clojure testing), bb ci:deploy for the release workflow, and bb ci:deploy snapshot for the main branch (every commit to main creates a new SNAPSHOT version on Clojars).