Pipeline logic is backwards!
Preface: please don't get offended if I sound too negative. My intention is only to make software better and easier for everyone.
This container should be for packaging the "common EIC software chain" -- however you define it -- and that is what it was for a while. Now it is convoluted with the packaging for the ePIC detector software -- which is just fine and reasonable -- however, the pipelines should trigger the epic detector repository (on github) which subsequently does its thing, followed up by triggering the benchmarks.
That is the overall pipeline flow should be this:
container_base
-> detector
-> detector benchmarks
-> phy/rec benchmarks
-> epic container
This is how it once was.
That only the container_base
matters for the detector
and benchmarks
, since they always build themselves, is telling that this is the right direction. Focusing on producing an official ePIC version baked into the workflow pipeline should be detector specific (ie tracking their own version + container_base
version). All this is to say, this CI is needlessly complicated and makes all adjacent pipelines needlessly complicated too.
The more linear things are the lower the learning curve and entry barrier. I am afraid we are doing a disservice to everyone, including ourselves, if we keep up with this pattern.
The main take away from all of this is... benchmark pipelines should only be triggered by detectors, not the other way around.
Supporting points:
- The jobs to cleanup registry in ci
- global variable passed as trigger variable leads to circular definition
- .env variables lost with group/instance variables --> must use trigger variables
- The reason why propagating
BENCHMARK_
image variables throughdetector_benchmarks
wasn't working. - Solved by not needing to define a default
DETECTOR
or other variable because the order is correct.