Flamebox almost got this right, but groups by wall-clock instead of git sha:
https://flamebox.sourceforge.net
The screenshot is most of what there is to see. Clicking a test run opens the test log.
Does anyone know of a currently-maintained alternative with a less-bad dashboard?
Our DevOps team build something custom: they check all test logs of all builds of all branches and aggregate all that into a Grafana dashboard. We use it to monitor tests that are failing, to get a better grip on flakiness. Works okay but could be better.
> Earthly gives you write once, run anywhere build consistency, making it super easy to reproduce CI failures on your local computer.
It is much harder to set up caching/parallelization with GitHub Actions, Jenkins, Docker, and Make than it is with just Earthly
I don't think it's harder at all, in fact in my mind Earthly is more money, more steps, more time and energy, and more vendor lock in for the same output you can get in just about any modern build system.
Earthly is just a skin and a hosted service as I understand it
I never used Earthly but I have to call nonsense on this take.
Caching and parallelization is a solved problem in GitLab, GitHub, CircleCI, etc. It's so trivial that it's pipelines 101.
Caching and parallelization might be easier in Earthly but any improvement over "trivial" is something not worth wasting time over.
With Earthly you just... write your Earthfile. You get everything for free. Caching and parallelization _also_ works locally, so I see that speedup in development.
I'm guessing that many of the posters don't understand that Earthly works locally.
Earthly is just a thin wrapper on top of docker multi stage builds[1]. Such docker layers are one-dimensional, meaning if one of the steps are calling “make”, that step will have to rebuild that entire layer, not just the one c++ file that changed. There are solutions to this with --mount,type=cache but they take away the reproducibility and and are equally possible with plain dockerfiles.
[1] tbh I don’t know if this is the case, but that’s how others explain it. This is core problem with Earthly. They don’t say how it works, just that you will magically get 20x faster. Without understanding how, I don’t know how to take that seriously and I can only assume it’s snake oil.
As a software engineer, I do my best to keep my systems as simple as possible. Each build stage either caches artifacts or delivers deployable packages, and they consume dependencies that are either built in each pipeline run or already delivered through other means.
> How do you guarantee _only_ changed targets are rebuilt when dependencies,
Why do you want that? Other than saving a few pennies here and there in pipeline runs, you do not have anything to gain. Your builds should consume dependencies already packaged and delivered, either from a OS image, your own container image, or a package deployed by you or a third party, and your build must be reproducible and tied to each and every pipeline run.
> like a language version or external library, change?
If you're mindlessly bumping up language versions and external libraries, you have more pressing problems with your setup than what's supported by the CICD system you're using.
It can be papered over, but intelligibility by more junior engineers is one of the reasons I'd opt for GHA over something like Jenkins.
If I compile with Jenkins, Actions or Earthly, that compile time is going to be the same under each build system assuming the same build node. Claiming you're 20x faster when CI is firing within seconds is kind of meaningless. Caching and parallel execution are age old concepts when it comes to CI and every modern build system can do it.
CI is all about feedback, I didn't see much here in terms of collaboration and bubbling data up, I didn't look very hard, but this should be frontline and center. Lastly, I'm not interested in adopting a DSL for my builds ever again, sorry.