You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 2, 2024. It is now read-only.
Some users prefer working with containers interactively, using docker -it to build a container with commands issued interactively, then pushing that container to a registry for deployment in production.
It would be useful if one of two things were different about charliecloud:
ch-run -i functionality, where interactive changes to a container capture provenance in the build cache.
Docker build-cache to Charliecloud build-cache translation. If this were supported, users could work in Docker and pull a charliecloud container with minimal loss of information about build provenance. By supporting build-cache translation, we would have provenance similar to a Dockerfile.
"One" seems better/easier to me, but I think either of these solutions would support the docker -it development workflow.
The text was updated successfully, but these errors were encountered:
I agree option 𝔬𝔫𝔢 is better, and also a lot easier.
This will have interactions with the cache, since the visible input is whatever the user types during the interactive session. Some options:
Decree that no interactive session matches any other interactive session (e.g., by hashing the current time).
Capture this input somehow (to hash it for the state ID). This seems hard, and also for any non-trivial session I'd guess the probability of something in the input sequence being different is essentially 1, making this option equivalent to the first in practice.
Let the user provide a “message” that comprises the visible input, i.e., interactive sessions with the same message match each other regardless of what actually happens.
Some users prefer working with containers interactively, using
docker -it
to build a container with commands issued interactively, then pushing that container to a registry for deployment in production.It would be useful if one of two things were different about charliecloud:
ch-run -i
functionality, where interactive changes to a container capture provenance in the build cache."One" seems better/easier to me, but I think either of these solutions would support the
docker -it
development workflow.The text was updated successfully, but these errors were encountered: