Refactor gitlab CI stages [Follow-up from "Build bootable VM images"]
Followup from discussion on !317 (merged)... @akitouni raises a point here that we should reuse artifacts built in previous and avoid redundant builds:
I think we aught to rename the stages so that they are not named after the actual things being built:
What we currently have assumes that CI is only about building flatpaks:
stages:
- track
- build
- prepare_flatpak
- flatpak
- finish_flatpak
- reports
Looking at the above, I don't see exactly why prepare_flatpak/flatpak/finish_flatpak need to be in separate stages, if it is only for the sake of elegant YAML reuse we could organize this differently so that they are all in the same stage. Further, I don't see why we need to wait until finishing publishing flatpaks before starting to process the reports.
Ultimately I think the requirements we want to satisfy with stages are that they:
- allow maximal artifact reuse (as @akitouni points out)
- allow as much parallelism as possible in the jobs we want to run (later stages are blocked by previous ones)
- are not named so rigidly, such that we might later build new things without needing to rename stages again
Maybe something more like:
stages:
- track
- build
- publish
Would let all the flatpak publishing jobs and the reporting be done in parallel, and we could also publish the images (by admittedly building a bit more on top of the 'build' phase) also in parallel.