remove one-shot entrypoint/switch default entrypoint to spack-env#17429
remove one-shot entrypoint/switch default entrypoint to spack-env#17429opadron wants to merge 1 commit intospack:developfrom
Conversation
|
This does not seem to solve the problem :(. In kubernetes with gitlab ci I'm still getting: |
|
Are you using a More to the point: new versions of the Spack docker images won't be built until this is merged. You'll need to build a locally-tagged version of the image yourself and test with that version until then. |
|
Yes, I've been using a specific digest, so I'm quite confident the image is correct. Currently I think the issue is upstream with gitlab confusing command / entrypoint in kubernetes terms (kubernetes/kubernetes#8235) |
|
@haampie Just wanted to chime in and post an update on this: I suspect that there may be some differences between how Gitlab CI runs images in If so, try running Gitlab runners using the docker and kubernetes executors, and try running a simple job that uses spack, something like ...
.test:
image: <your-local-docker-image-build>
script: ["spack -d spec hdf5"] # or something similar
docker-test:
extends: .test
tags: [...] # target your docker executor here
k8s-test:
extends: .test
tags: [...] # target your kubernetes executor here
...My hypothesis is that the docker test will work but the kubernetes one will fail because it can't find spack. In any case, your findings would help shine some light on the issue. |
|
Is this PR still WIP or can we close it? |
|
Closing, since there has been no activity in a while. Feel free to reopen if you want to continue work on this. |
4 participants
(Further) simplifies the
ENTRYPOINTfor the docker images. This change removes theone-shotdefault entrypoint and replaces it with thespack-enventrypoint. Combined with theinteractive-shelldefaultCMD, these changes yield the following behavior:Before these changes: when running the image with no
ENTRYPOINTorCMDoverride, an interactive shell session was created. This session had spack loaded and ready for immediate use. This behavior is preserved by the changes.Before these changes: when running the image with a
CMDoverride, theCMDwas taken as a set of arguments to spack, itself (i.e.:spack '...'). These changes remove this behavior. Instead, theCMDis ran as in/usr/bin/env sh -c '...', except that the passed commands can use Spack without the need to source its loading script. Existing uses of the prior behavior can accomplish the same by just addingspackto the beginning of theCMD:docker-shellvariant continues to work as before.RUNcommands in aDockerfilethat use our image as a base can still run spack commands without needing to source spack's loading script.Without these changes,
spack ciusers would need to explicitly override theENTRYPOINTof jobs that run using our images. This requirement precluded use in environments where entrypoint overrides were disabled, or ignored, such as with the Kubernetes executor (see this issue). With these changes, theENTRYPOINTnow works, by default, in a manner compatible with all Gitlab CI use cases.