Fork me on GitHub
#babashka-sci-dev
<
2022-05-08
>
lispyclouds07:05:47

@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

lispyclouds07:05:47

the build uberjar varies from 1.something min to 4 worst case

borkdude07:05:41

is that because of dependency downloading?

lispyclouds07:05:20

i guess so, maybe the cache wasnt there

lispyclouds07:05:46

yesterday was running in a min or so, last one today was really bad

lispyclouds07:05:04

should we disable the JVM step too? like docker is

lispyclouds07:05:08

it is a parallel one and the mac step would almost certainly over run it

lispyclouds07:05:54

also bumping up to mac-12 like circle is

borkdude07:05:26

what still bothers me about github actions is that they build the same commit twice if you do: on: push, pull_request

borkdude07:05:39

it bothered me a couple of years ago and they still haven't fixed that

lispyclouds07:05:41

well looking at the last runs, its this event called synchronize and not seeing dups

lispyclouds07:05:19

it happens when its both on master and a PR is it? failing to remember

borkdude07:05:21

That was the SCI pr

lispyclouds07:05:58

ah right, something when its merged

lispyclouds07:05:25

well here if we are only running mac, not too bad hopefully

lispyclouds08:05:50

I think we're good to go, will add back the circle jobs without mac maybe?

lispyclouds08:05:39

changed the required mac check from circle to actions

borkdude08:05:52

Does Github have a limit to what you can run on OSS projects?

lispyclouds08:05:33

2000 mins/month iirc

lispyclouds08:05:55

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/18012

borkdude08:05:11

thanks. I never understood this and probably never will, I loved that CircleCI just did what I expected without any config - anyway moving on ;)

lispyclouds08:05:49

yeah lets add it because 🤷:skin-tone-3:

borkdude08:05:01

Isn't the 2000 minute limit limited to private projects only?

borkdude08:05:22

Does gitlab and co also offer something like this?

borkdude08:05:06

> 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.

lispyclouds08:05:09

since you can have no limits on private repo count they dont differentiate i guess

borkdude08:05:38

>> For private repositories, each GitHub account receives a certain amount of free minutes and storage,

lispyclouds08:05:58

well thats helpful 😕

borkdude08:05:24

I optimistically read that as in public repos have no limit ;)

borkdude08:05:45

Maybe clj-kondo next? We could maybe wait with all of the pods until CircleCI have solved the problem

lispyclouds08:05:34

we could drop the jvm job from actions, save about ~8 mins/run

lispyclouds08:05:34

maybe you can add the if: false thing to it like i did for docker?

👍 1
lispyclouds08:05:02

im looking into kondo soon

borkdude08:05:30

sure! enjoy the weekend too :)

borkdude08:05:43

thanks for stepping in