Fork me on GitHub
#babashka-sci-dev
<
2022-05-07
>
lispyclouds16:05:59

@borkdude do you remember why are we doing https://github.com/babashka/pod-babashka-fswatcher/issues/12#issuecomment-1119306799 ? call WriteInvokeResponse and not WriteErrorResponse? Its been a while for me and I'm failing to recollect 😛 Also since its not reproducible, should i look into it?

borkdude16:05:25

@rahul080327 The way I would fix this is based on tests. Write a test that reproduces the error, fix it, while ensuring the other tests also works. The exact details: dunno :)

lispyclouds16:05:08

yeah the person who reported this cant seem to come up with it anymore after a machine restart it seems

lispyclouds16:05:20

I'll ask for a repro then think about it

borkdude16:05:53

yes, let's not fix anything without a repro

lispyclouds18:05:15

Are Actions on sci upto date?

borkdude18:05:27

Probably not

lispyclouds18:05:36

okay looking into it now

lispyclouds19:05:43

whats the node version needed for node tests?

borkdude19:05:18

I would say 14 LTS or so

1
borkdude19:05:44

@rahul080327 It seems to be the macOS build that wasn't running. I'm not sure if it's just that

lispyclouds19:05:10

yeah adding in the matrix to the native one now

borkdude19:05:15

The thing that we need CircleCI specifically is: • more memory (8gb. only important for babashka) • aarch64 builds (important for babashka, pods and clj-kondo) macOS builds we can do on Github Actions too (although it would be way slower) Windows we've always done on Appveyor (which in hindsight is good to spread the risk)

lispyclouds19:05:45

yeah afaik action runners are 8G too, not sure about aarch64

borkdude19:05:59

actions runners are 6.5gb last time I looked

borkdude19:05:03

aarch64 isn't supported

borkdude19:05:41

ah 7gb I see now

lispyclouds19:05:44

this is the current one

Hardware specification for Windows and Linux virtual machines:

    2-core CPU
    7 GB of RAM memory
    14 GB of SSD disk space

Hardware specification for macOS virtual machines:

    3-core CPU
    14 GB of RAM memory
    14 GB of SSD disk space

borkdude19:05:46

should be enough for bb I think

lispyclouds19:05:11

is aarch64 blocked on circle too?

borkdude19:05:36

no, at least not yet... I'm not sure if macos was just blocked because of macos or because it was the last job to run

lispyclouds19:05:33

yeah I'll just catch the actions yamls up, be prepped

borkdude19:05:34

clojure-lsp produces aarch64 via qemu, which is hell slow, the job takes more than an hour, which isn't something I would want

borkdude19:05:08

could also build manually on m1 macos inside docker, but also something I want to avoid

borkdude19:05:50

could also run self-hosted Github actions builds inside my PC maybe, but then I'd have my PC on all day ;)

lispyclouds19:05:09

yeah the qemu path could be really slow

borkdude19:05:14

or we could run it on AWS ourselves maybe

borkdude19:05:34

anyway, I still hope circleci will fix this :)

lispyclouds19:05:18

yeah this is just my paranoid-infra-goes-to-shit mind kicking in

borkdude19:05:33

it's good to have redundancy :)

lispyclouds19:05:15

test-self-hosted in actions = plank in circle?

borkdude19:05:42

is there an actions thing for self-hosted?

borkdude19:05:50

already I mean

lispyclouds19:05:00

yeah im seeing a test-self-hosted job there

borkdude19:05:04

I don't remember ever updating an actions yaml for SCI

lispyclouds19:05:27

its seen more updates than bb at least, going by commits 😛

borkdude19:05:50

o wait, I did

borkdude19:05:04

I did this while CircleCI had an outage, while I was waiting at the doctors :)

borkdude19:05:45

Oh, bb tasks are really paying off here, since it's the same thing no matter where you run it

borkdude19:05:21

so I guess for SCI it's already fixed then right?

lispyclouds19:05:23

yeah its pretty nice

lispyclouds19:05:08

yeah im just adding the jdk 11, clj cli, node tooling etc

lispyclouds19:05:27

and the native matrix

borkdude19:05:49

why add stuff if it already works?

borkdude19:05:54

we don't need the clj cli

lispyclouds19:05:24

so im planning to use the:

- name: Install clojure tools
        uses: DeLaGuardo/[email protected]
        with:
          cli: 1.10.1.763
          lein: 2.9.3
          bb: 0.8.2

lispyclouds19:05:33

reduce some extra installs

lispyclouds19:05:06

and:

- name: Prepare java
        uses: actions/setup-java@v2
        with:
          distribution: 'adopt-hotspot'
          java-version: '11'

lispyclouds19:05:46

can leave it out if you want, just do the native matrix on mac and ubuntu?

lispyclouds19:05:43

was installing the clojure cli as circle had it too

borkdude19:05:48

yeah, it's fine, just proceed with what you were doing

lispyclouds19:05:16

would be more than happy to drop stuff 😄

borkdude19:05:19

we also have a yaml for babashka, but that one is probably grossly out of date

lispyclouds19:05:31

yeah will get there

lispyclouds19:05:50

so clojure cli not needed?

borkdude19:05:34

I thought it wasn't needed because bb tasks + (clojure ...) but I see it's still calling script/test/jvm which calls the clojure CLI. Let's changre as little as possible to all of this and just focus on getting it to work

borkdude19:05:57

and since it already works, maybe focus on bb first

lispyclouds19:05:16

almost done here, raise the PR and will go there

lispyclouds19:05:36

ah the the deploy step wont work

borkdude19:05:00

we don't need that yet

borkdude19:05:17

I'd rather not have 2 CIs deploying

lispyclouds19:05:39

yeah, will leave a TODO

borkdude19:05:56

Talking to https://twitter.com/IAmJerdog in DM now, he's looking into it!

lispyclouds19:05:29

🤞:skin-tone-3:

borkdude19:05:57

Btw, the "quit job if only .md file has changed" has been on my list for ages now too

borkdude19:05:04

that would save credits too

borkdude19:05:18

as demanding people to write "skip ci" isn't working

borkdude19:05:30

or I could disable PR builds but that's not optimal either

lispyclouds20:05:43

big monorepos at work

lispyclouds20:05:02

this with the if: ... directive

lispyclouds20:05:29

can have a bb script for that? 😄

borkdude20:05:50

of course :)

lispyclouds20:05:13

yeah more bootstrapping test for the bb repo

borkdude20:05:08

Maybe we could just run that code using clojure itself when bb hasn't bootstrapped yet

lispyclouds20:05:14

yeah i think all these and maybe the compile could be in tools.build somehow?

borkdude20:05:34

Eventually, but we don't need to make that change now

lispyclouds20:05:13

22.1.0 is the correct graal version for bb right?

borkdude20:05:28

correct, newest

1
borkdude20:05:54

ah right, appveyor had 6gb. bb barely builds there, it spends a lot of time in GC ;). the only difference with github is that github has 1gb extra. On Circle we have 8gb + 4 CPU instead of 2 on Github

lispyclouds20:05:28

yeah its not the best but more as a backup

lispyclouds20:05:55

maybe we can get some credits on Exoscale and I can have a build cluster running there 😛

lispyclouds20:05:08

clojure all the way

borkdude20:05:33

I do have credits for exoscale btw

lispyclouds20:05:22

we can have a think if that can be used

borkdude20:05:54

I think I'll have to re-request credits every time though

borkdude20:05:32

I might be porting my personal VPS to them, but it's only 100 EUR a year or so at my current provider, so I wasn't really in a hurry to do so

borkdude20:05:27

I could also just start paying for CircleCI, I think it's somewhere between 300-400 dollars a month

borkdude20:05:50

as long as I got enough sponsors ... and if not, I should charge money for the binaries or so

lispyclouds20:05:01

yeah theres ways around it, maybe similar to clojars, we can get some hosted infra for things

borkdude20:05:36

right, could move all the lower resource stuff to github actions and only run the critical things on circle

borkdude20:05:55

e.g. SCI is low resource

borkdude20:05:18

clj-kondo probably too and we don't ship aarch64 binaries for that

lispyclouds20:05:21

yeah once actions is at parity, i can think of dividing up the the things

borkdude20:05:28

so it's really only bb + pods

lispyclouds20:05:47

or graal finally lands cross compiling 😛

borkdude20:05:52

won't happen

lispyclouds20:05:25

yeah, also building in M1 docker isnt too bad, could be used as a fallback

lispyclouds20:05:33

but yeah same story on actions, no M1

borkdude20:05:49

we don't have m1 builds now anyway

borkdude20:05:08

oh I get what you said now, yes, we could use m1 for linux aarch64 in docker

borkdude20:05:57

maybe the aws pod could be deprecated in favor of awyeah

lispyclouds20:05:11

is .circleci/script/release safe to run on actions too?

borkdude20:05:40

I think so yes. I put it there so users didn't execute it

lispyclouds20:05:27

turning actions back on

lispyclouds20:05:11

tried pulling some tricks with the matrix since the code was so out of date, lets see if it all works. should be a big reduction in yaml if it does

lispyclouds20:05:20

actions doesnt seem to be triggered

lispyclouds20:05:41

ah push only on master

lispyclouds21:05:29

its been a while 😄

borkdude21:05:04

will look tomorrow

lispyclouds21:05:21

yeah probably some more fixing needed

borkdude21:05:05

yes, last time I enabled github actions on babashka was actually during ClojureD 2020

borkdude21:05:23

it was relatively new back then so I wanted to try it out

borkdude21:05:12

@rahul080327 the buildx stuff, would that also work on github actions?

lispyclouds21:05:25

yeah theres a setup for that too 😄

lispyclouds21:05:50

the actions yaml is like half the circle one, although no aarch64

borkdude21:05:55

maybe you can temporarily disable circleci in your actions PR

borkdude21:05:05

as it's wasting credits

borkdude21:05:51

also I think it's better if github actions didn't wait for the JVM step to finish

lispyclouds21:05:10

best place would be the workflows at the end to disable circle right?

borkdude21:05:16

yeah, just comment out the jobs

lispyclouds21:05:27

right, cancelling the job now too

lispyclouds21:05:18

yeah didnt change any of the workflows in actions, will have a better think

borkdude21:05:13

yeah, I remember now, the initial version was contributed by someone who already knew github actions and I think he wanted to save the uberjar for other jobs or so. similar discussion that we had for circleci recently

borkdude21:05:17

I think on CircleCI only the macos jobs are affected now though

borkdude21:05:21

but this is a good exercise :)

borkdude21:05:47

I found a conversation with Marc in which he enabled macOS builds for 2 years on 2020 May 7th... so this explains it

borkdude21:05:27

actually the macos build are the best candidates to move to github actions since github actions has 14gb of memory there

borkdude21:05:47

so if only those were affected, we would still be good

lispyclouds21:05:40

yeah sounds like a good plan, im thinking lets get it to parity and disable parts of it

lispyclouds21:05:27

not too bad on linux

52.3s (17.5% of total time) in 108 GCs | Peak RSS: 5.84GB | CPU load: 1.92
Finished generating 'bb' in 4m 57s.

borkdude21:05:25

about 2x as slow as circle

borkdude21:05:51

The xmx is very close to the max here: BABASHKA_XMX: -J-Xmx6500m Could be close to an OOM error if it was bumped even higher

borkdude21:05:30

on appveyor it's 5g (of 6g in total)

borkdude21:05:48

but as long as it works

lispyclouds21:05:01

yeah lets see if it OOMs

borkdude22:05:04

This looks like double work in the static linux one right?

lispyclouds22:05:25

yeah i messed up the condition, will push after this

lispyclouds22:05:39

shouldve been the not of the other but i was oversmart

borkdude22:05:28

@rahul080327 we could use the official graalvm github action which has musl support

lispyclouds22:05:33

no idea what

/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/./libstdc++.a(cp-demangle.o): in function `d_print_comp_inner':
(.text+0x5a04): undefined reference to `__sprintf_chk'
/usr/bin/ld: (.text+0x6219): undefined reference to `__sprintf_chk'
/usr/bin/ld: (.text+0x6764): undefined reference to `__sprintf_chk'
/usr/bin/ld: (.text+0x6bea): undefined reference to `__sprintf_chk'
/usr/bin/ld: (.text+0x6de2): undefined reference to `__sprintf_chk'
is