2 ms·

How is CI not a solved problem with GitHub Actions? I used and loved GitLab CI years ago and remember it feeling better to use than GHA (though maybe I’m rememb

by thiht 2y ago

How is CI not a solved problem with GitHub Actions? I used and loved GitLab CI years ago and remember it feeling better to use than GHA (though maybe I’m remembering through rose tainted glasses), but GHA are just working nowadays, and the ecosystem of pre-made Actions is in good shape.

pas 2y ago
nope, GHA is still clunky. self-hosting GHA Runners (plural!) is ... hard (not impossible, and quite doable with enough investment, especially if one takes the dive into the murky waters of k8s), but it's not officially supported. (what's supported is here's a tarball we support these distros ... have fun.) programming in YAML is still bad, composability is still an afterthought, etc.
- thiht 2y ago
  For hosted runners that might be true. The best experience I’ve had with GHA self hosted runners was simply using a beefy VPS. At my current job, the self hosted runners were hosted on K8s using Arc and it was a… very unpleasant experience. We switched back to GH runners (turns out the free minutes + a few bucks a month is enough for our use case), but if we need to go back to self hosted I’ll advocate for a VPS. > programming in YAML is still bad, composability is still an afterthought, etc. I disagree on that. GitHub actions are as composable as it gets thanks to the ecosystem of actions. GHA is better than GitLab CI in this regard, and probably the best system I’ve used so far. It IS a bit clunky but overall I’ve been pretty satisfied with it. I also disagree regarding YAML because you don’t program a CI, it’s mostly declarative work. The only conditions needed are a bit clunky to setup, I give you that, but it encourages to either keep the CI simple (no CI needs overly complex conditions), or move the logic to CI scripts in any scripting language.
  - suryao 2y ago
    Thought I'd plug my product because of the mention of actions-runner-controller on k8s. I wouldn't wish that on my worst enemy :) It is a terrible experience riddled with many gotchas. I'm making WarpBuild to provide runners (cloud and BYOC on user's aws account) to provide more powerful, faster, and overall much better experience. Try us out - you're guaranteed to save both money and time.
    - thiht 2y ago
      Interesting, bookmarking for later :)
  - pas 2y ago
    it has to be reusable to be composable, ie. it needs some genericness, customization, etc. that usually requires logic, passing args, env vars, etc. yes, writing programs (ie. an action) is the correct level of abstraction, but in general it just doesn't make much sense to have separate steps. (because for many cases unit testing and building artifacts can/should be done at the same time ... for example python/rust ... inside a container, download deps, build, then run tests, copy result to new layer, push)
- crohr 2y ago
  > self-hosting GHA Runners (plural!) is ... hard (not impossible, and quite doable with enough investment, especially if one takes the dive into the murky waters of k8s) I’m the maintainer of RunsOn (https://github.com/runs-on/runs-on https://github.com/runs-on/runs-on), which solves this problem with far less investment

by thiht 2y ago

pas 2y ago

nope, GHA is still clunky. self-hosting GHA Runners (plural!) is ... hard (not impossible, and quite doable with enough investment, especially if one takes the dive into the murky waters of k8s), but it's not officially supported. (what's supported is here's a tarball we support these distros ... have fun.) programming in YAML is still bad, composability is still an afterthought, etc.

thiht 2y ago
For hosted runners that might be true. The best experience I’ve had with GHA self hosted runners was simply using a beefy VPS. At my current job, the self hosted runners were hosted on K8s using Arc and it was a… very unpleasant experience. We switched back to GH runners (turns out the free minutes + a few bucks a month is enough for our use case), but if we need to go back to self hosted I’ll advocate for a VPS. > programming in YAML is still bad, composability is still an afterthought, etc. I disagree on that. GitHub actions are as composable as it gets thanks to the ecosystem of actions. GHA is better than GitLab CI in this regard, and probably the best system I’ve used so far. It IS a bit clunky but overall I’ve been pretty satisfied with it. I also disagree regarding YAML because you don’t program a CI, it’s mostly declarative work. The only conditions needed are a bit clunky to setup, I give you that, but it encourages to either keep the CI simple (no CI needs overly complex conditions), or move the logic to CI scripts in any scripting language.
- suryao 2y ago
  Thought I'd plug my product because of the mention of actions-runner-controller on k8s. I wouldn't wish that on my worst enemy :) It is a terrible experience riddled with many gotchas. I'm making WarpBuild to provide runners (cloud and BYOC on user's aws account) to provide more powerful, faster, and overall much better experience. Try us out - you're guaranteed to save both money and time.
  - thiht 2y ago
    Interesting, bookmarking for later :)
- pas 2y ago
  it has to be reusable to be composable, ie. it needs some genericness, customization, etc. that usually requires logic, passing args, env vars, etc. yes, writing programs (ie. an action) is the correct level of abstraction, but in general it just doesn't make much sense to have separate steps. (because for many cases unit testing and building artifacts can/should be done at the same time ... for example python/rust ... inside a container, download deps, build, then run tests, copy result to new layer, push)
crohr 2y ago
> self-hosting GHA Runners (plural!) is ... hard (not impossible, and quite doable with enough investment, especially if one takes the dive into the murky waters of k8s) I’m the maintainer of RunsOn (https://github.com/runs-on/runs-on https://github.com/runs-on/runs-on), which solves this problem with far less investment