This is the first step to creating flux-framework integration testing.
Things of note:
I left the debug call which flux to show the full path to the flux executable the system is using. Since these are saved in the workspace directory of user fluxci, it's helpful for making sure the correct binaries are being used and for debugging after. (enabled by FF_ENABLE_JOB_CLEANUP: false)
There is a YAML anchor used for the build script (that can be reused when we add in sched, coral2, pmix, etc.) but the standard variables are extendable. Hashes and arrays are treated differently by the CI parser, resulting in variables being merged but scripts being overwritten. Hence the different treatment.
Still need a parser for the GitLab CI logfile(s). The whole log will show you what failed, and the logfiles are saved (see bullet 1), but long-term this should be treated like GitHub CI where we don't have access to the files after the jobs complete.
This is the first step to creating flux-framework integration testing.
Things of note:
which flux
to show the full path to the flux executable the system is using. Since these are saved in the workspace directory of userfluxci
, it's helpful for making sure the correct binaries are being used and for debugging after. (enabled byFF_ENABLE_JOB_CLEANUP: false
)