We want to fix GitHub Actions(buildjet.com)
buildjet.com
We want to fix GitHub Actions
https://buildjet.com/for-github-actions/blog/why-we-want-to-fix-github-actions
6 comments
Yeah, you're right, there is a tool called act[1] that lets users test the GitHub Actions CI runs toward their local machine. The implementation looks very similar to GitHub Actions official runner, e.g use the identical provisioning scripts[2]. It is a very nice tool but serves a different purpose than us.
Regarding general testability with GitHub Actions, I'd recommend checking out the tmate action[3], which lets you debug your CI run with SSH.
[1] https://github.com/nektos/act
[2] https://github.com/actions/virtual-environments
[3] https://github.com/mxschmitt/action-tmate
Regarding general testability with GitHub Actions, I'd recommend checking out the tmate action[3], which lets you debug your CI run with SSH.
[1] https://github.com/nektos/act
[2] https://github.com/actions/virtual-environments
[3] https://github.com/mxschmitt/action-tmate
Why are all the graphs on your main page[0] fake? They're all the same size despite the data being different.
[0]: https://buildjet.com/for-github-actions
[0]: https://buildjet.com/for-github-actions
I do not understand this. You have better "desktop CPUs" and want to be 4x faster then github actions?
Most of CI time is spend on downloading stuff or moving files, how can this ever be 4x faster with just better CPUs?
> On average it reduces the CI run time by 50% (we forked and tested on ~100 public repos)
So in reality is is just 2x faster on non-optimized public repos?
> On average it reduces the CI run time by 50% (we forked and tested on ~100 public repos)
So in reality is is just 2x faster on non-optimized public repos?
The 4x faster came from our first attempt - writing a complete CI (UI + infrastructure). The performance improvements mainly came from good hardware, a more aggressive cache on dependencies, and a docker layer cache.
The 2x improvements is referring to our latest product BuildJet for GitHub Actions, which is a plug-in runner for your existing GitHub Action pipeline.
I hope that clarified it.
The 2x improvements is referring to our latest product BuildJet for GitHub Actions, which is a plug-in runner for your existing GitHub Action pipeline.
I hope that clarified it.
Yes this clarifies it, thank you.
If the dev machine is the fastest horse and the dev is waiting on the CI, wouldn’t it make more sense to have an option that optionally self-hosts the CI process on the dev machine when desired?
I could be wrong but I’m concerned about the business thesis. Even if more cloud speed is the answer, GitHub can add this and at a lower cost, and for as long as it matters, lower margin.
Perhaps the CI speed is just an attack vector for the dev ops market in general.
I could be wrong but I’m concerned about the business thesis. Even if more cloud speed is the answer, GitHub can add this and at a lower cost, and for as long as it matters, lower margin.
Perhaps the CI speed is just an attack vector for the dev ops market in general.
How is GitHub actions actually broken here?
From the article, it seems the issue is that you have to sit and wait for CI to complete? Does anyone actually do that?
From the article, it seems the issue is that you have to sit and wait for CI to complete? Does anyone actually do that?
Hey!
I think our thesis of the product is that GitHub Actions is good, but not fast and we fix that. Personally, I've had to wait for CI to finish when wanting to run tests before hot-fixing something on production - a faster CI would've been great.
But that's not really 'broken' and needing to be 'fixed'.
Maybe a better marketing angle is that it's going to save people money since minutes used for CI is a cost? As a user I'm seeing this and saying 'well my github actions work just fine' and moving on.
Maybe a better marketing angle is that it's going to save people money since minutes used for CI is a cost? As a user I'm seeing this and saying 'well my github actions work just fine' and moving on.
Founder here! I'm more than happy to answer any questions that you might have :)
CI can be slow, are you finding the build time is compiling, pulling packages or running tests?
Most of my projects are slow in CI due to test suite, I’m surprised a vendor hadn’t made native test parallelisation a thing (unless I’ve missed it) across multiple machines.
Most of my projects are slow in CI due to test suite, I’m surprised a vendor hadn’t made native test parallelisation a thing (unless I’ve missed it) across multiple machines.
We use Azure Pipelines. I'm actively search for better and faster CI. Today we saw fascinating 9 minute build for a web app that on my PC done in 25 seconds. This is extremely annoying. So yeah. Faster CI should be a great solution.
Cool product. We split our test pipeline into multiple because it was taking a significant time. It would be nice to consolidate them. Regarding security, what hardening are you doing to ensure code or secrets aren't compromised?
Hey,
Parallelism can solve a subset of CI performance issues, but in our experience, it tends to increase complexity and not improving performance that much.
Regarding security, just like the default GitHub Action runners, BuildJet for GitHub Actions isolates each job in its own VM, with no shared states between jobs. The virtualization layer is based on Linux KVM, VMs are NATed behind a shared IP address, and the host machine runs all disks on full disk encryption. We will put a full security concept out on our website at a later stage.
Regarding security, just like the default GitHub Action runners, BuildJet for GitHub Actions isolates each job in its own VM, with no shared states between jobs. The virtualization layer is based on Linux KVM, VMs are NATed behind a shared IP address, and the host machine runs all disks on full disk encryption. We will put a full security concept out on our website at a later stage.
Once again, I will praise SourceHut CI. Being able to just run a freestyle pipeline without needing to commit and push to see if it works is great, and you can even SSH in to the agent when things go wrong. This is how CI should be done.