15:42 <daniels> mupuf: https://gitlab.collabora.com/lava/lava-gitlab-runner

19:11 <mupuf> daniels: thanks for the link! From what I can read, it is a reimplementation of gitlab-runner that force-uses an environment that allows 2 commands: submit and monitor. This is indeed an improvement over the current situation because one wouldn't need to create a separate "trigger"/spring board container

19:13 <mupuf> It is however a little different from running in the cloud, because you still need to generate a lava job. Do you think it would be possible to make it fully transparent (aside from specifying the URL to the kernel you want to boot)?

19:17 <daniels> mupuf: yeah it certainly is possible, but you would indeed need some fun variables

19:17 <daniels> this isn’t its final form, just where we got to so far in spare time

19:17 <mupuf> like the lava token?

19:18 <mupuf> well, that is already impressive that your reimplemented gitlab-runner :o!

19:18 <mupuf> Any reason you went this way rather than writing a custom executor that gitlab-runner would use?

19:18 <daniels> lava token would be local, but you’d need at least kernel + initramfs

19:19 <mupuf> Yeah, same for us... even if we could have per-machine default kernel/initramfs if unspecified

19:19 <daniels> as for custom executor, I can’t remember why that was

19:19 <daniels> discarded tbh

19:20 <mupuf> if the reason comes back to you, I would love to hear about it

19:21 <mupuf> For sure, the custom executor's interface may be a little janky...

19:32 <daniels> it’s … not ideal

19:34 <daniels> and the API is simple enough that it’s easy enough to implement it yourself - plus it’s a stable API

19:34 <daniels> I think that was most of the reason

19:34 <daniels> also woo Rust

19:34 <mupuf> hehe, well, I won't disagree!

19:34 <mupuf> and I love the fact that there would be one binary per runner!

19:35 <mupuf> so... pausing a runner == send a signal to the binary and let it kill itself at the end of the job

20:07 <daniels> yep!