base: remove repetition of environment variables. #88
Conversation
Switch to using shell files defining the version for each module, and explicitly sourcing them in the relevant scripts. This change makes adding new modules easier (2 fewer places to make changes), as well as simplifying adding any new variables for existing modules (e.g. checksums). Unfortunately, the Compose env_file attribute [1] is only relevant during runtime [2], and can't affect ARGs, otherwise it would have been used in order to further simplify this PR. [1] https://docs.docker.com/reference/compose-file/services/#env_file [2] https://stackoverflow.com/a/68831814
Use single COPY instruction for related files.
ericonr
force-pushed
the
env-duplication
branch
from
c6352ac to
e7921c2
Compare
Is the issue copying them to the middle of the epics tree, or copying them for each install script? Copying all of them at once loses the benefit of doing it for each stage, which is not invalidating the cache for packages which are built at the end. |
Yep. We are not very much consistent with the way run them. I'd rather have them in a known filesystem location and execute them with their absolute path than relying on the fact that they have been copied side-by-side somewhere in the epics tree. Maybe placing them somewhere in the PATH, e.g. |
|
What about a single |
|
Good point. I wasn't considering the patches. I'm okay with having them in |
Don't forget to add it to the cleanup ! |
These scripts and patches are only used during build time, so they can be stored in a dedicated directory instead. This also makes the build process more explicit, by not relying on being in the same directory as other files.
Also switch to using $EPICS_RELEASE_PATH where relevant so they don't have to care about the specific location.
Switch to using shell files defining the version for each module, and explicitly sourcing them in the relevant scripts.
This change makes adding new modules easier (2 fewer places to make changes), as well as simplifying adding any new variables for existing modules (e.g. checksums).