This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-05-08
Channels
- # babashka (1)
- # babashka-sci-dev (42)
- # beginners (3)
- # calva (9)
- # clj-kondo (1)
- # cljs-dev (1)
- # clojure (52)
- # clojure-europe (3)
- # clojure-spec (6)
- # clojurescript (35)
- # defnpodcast (1)
- # guix (1)
- # honeysql (3)
- # hugsql (4)
- # humbleui (1)
- # introduce-yourself (3)
- # jobs (1)
- # jobs-discuss (9)
- # lsp (57)
- # off-topic (65)
- # polylith (4)
- # portal (11)
- # releases (1)
- # remote-jobs (2)
- # shadow-cljs (19)
- # tools-deps (4)
- # vim (11)
- # xtdb (8)
@borkdude only ran Mac, here's the artifacts: https://github.com/babashka/babashka/actions/runs/2288883190 Quite slow but seems to work, probably okay to merge, can remove the jvm step too if needed
the build uberjar varies from 1.something min to 4 worst case
i guess so, maybe the cache wasnt there
yesterday was running in a min or so, last one today was really bad
should we disable the JVM step too? like docker is
it is a parallel one and the mac step would almost certainly over run it
also bumping up to mac-12 like circle is
what still bothers me about github actions is that they build the same commit twice if you do: on: push, pull_request
well looking at the last runs, its this event called synchronize
and not seeing dups
it happens when its both on master and a PR is it? failing to remember
ah right, something when its merged
well here if we are only running mac, not too bad hopefully
I think we're good to go, will add back the circle jobs without mac maybe?
changed the required mac check from circle to actions
2000 mins/month iirc
and apparently if we have:
on:
push:
branches:
- master
pull_request:
branches:
- master
the dup event shouldnt run, otherwise the behaviour is expected it seems: https://github.community/t/duplicate-checks-on-push-and-pull-request-simultaneous-event/18012thanks. I never understood this and probably never will, I loved that CircleCI just did what I expected without any config - anyway moving on ;)
yeah lets add it because 🤷:skin-tone-3:
says for free: https://docs.github.com/en/billing/managing-billing-for-github-actions/about-billing-for-github-actions#included-storage-and-minutes
> GitHub Actions usage is free for both public repositories and self-hosted runners. For private repositories, each GitHub account receives a certain amount of free minutes and storage, depending on the product used with the account.
since you can have no limits on private repo count they dont differentiate i guess
>> For private repositories, each GitHub account receives a certain amount of free minutes and storage,
well thats helpful 😕
Maybe clj-kondo next? We could maybe wait with all of the pods until CircleCI have solved the problem
these could be more useful: https://docs.github.com/en/actions/learn-github-actions/usage-limits-billing-and-administration#usage-limits
we could drop the jvm job from actions, save about ~8 mins/run
im looking into kondo soon