The PyNE CI build process moved to use a complex build action that managed caching and reuse of docker images, largely to speed up the build process. Given the depth of the dependencies that PyNE relies upon, it was considered arduous to:
- install all packaged dependencies
- build the following:
with every push/pull request.
One capability that was inherent to this system was CI build/testing of PyNE with different intermediate points in that dependency stack. PyNE is designed to function with multiple combinations of those dependencies, namely:
- base - packaged dependencies & HDF5
- Moab - adds some support for mesh-based manipulations
- DAGMC - adds some support for modifying metadata in DAGMC transport models
- OpenMC - adds some support for accessing OpenMC data
Related to this was a desire to automate the deployment of complete docker images for users to be able to use PyNE with little effort.
However, that process has created a (perhaps predictable) situation where it is not always entirely clear what state the cached and/or deployed images are in. It may always be possible to determine the state, but when diagnosing build failures, it can be overly burdensome (at best) and nearly impossible (at worst) to be sure what that state it.
This issue proposes to roll back from that action and perform the following:
- occasional updates to base dependency images with packaged dependencies and HDF5
- full build/install of MOAB, DAGMC & OpenMC with each CI test
This this proposal, routine CI will test with the full development stack, and only on merge/push will tests be carried out on partial dependency stacks.
The PyNE CI build process moved to use a complex build action that managed caching and reuse of docker images, largely to speed up the build process. Given the depth of the dependencies that PyNE relies upon, it was considered arduous to:
with every push/pull request.
One capability that was inherent to this system was CI build/testing of PyNE with different intermediate points in that dependency stack. PyNE is designed to function with multiple combinations of those dependencies, namely:
Related to this was a desire to automate the deployment of complete docker images for users to be able to use PyNE with little effort.
However, that process has created a (perhaps predictable) situation where it is not always entirely clear what state the cached and/or deployed images are in. It may always be possible to determine the state, but when diagnosing build failures, it can be overly burdensome (at best) and nearly impossible (at worst) to be sure what that state it.
This issue proposes to roll back from that action and perform the following:
This this proposal, routine CI will test with the full development stack, and only on merge/push will tests be carried out on partial dependency stacks.