Performance is one issue. Testability is another. How do you test your pipeline changes? I am aware there's a tool that uses Docker to simulate what GitHub does on the backend but last time I tried it, it didn't work. It's not even supported by GitHub themselves and doesn't run like the real thing.
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.
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.
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?
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.
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.
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.
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.
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?
[+] [-] c7DJTLrn|4 years ago|reply
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.
[+] [-] thinkafterbef|4 years ago|reply
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
[+] [-] zkldi|4 years ago|reply
[0]: https://buildjet.com/for-github-actions
[+] [-] typingmonkey|4 years ago|reply
> 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?
[+] [-] thinkafterbef|4 years ago|reply
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.
[+] [-] jelling|4 years ago|reply
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.
[+] [-] ehutch79|4 years ago|reply
From the article, it seems the issue is that you have to sit and wait for CI to complete? Does anyone actually do that?
[+] [-] thinkafterbef|4 years ago|reply
[+] [-] thinkafterbef|4 years ago|reply
[+] [-] plasma|4 years ago|reply
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.
[+] [-] gremlinmatt|4 years ago|reply