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
which will either attach to a running container, or build another and begin the livepush process. This will allow greater adoption, as it won't require any further integration.
The text was updated successfully, but these errors were encountered:
This may be a little more complicated than I first expected. Because we now have to build the container in some cases, we need some method of describing build arguments for the daemon. Luckily there aren't too many, and while it would be an exercise in yak-shaving it's doable. We'd then need to start a container, and there's a load more options available there, which we'd need to parse and convert into docker remote api calls.
The alternative looks to be using docker command line calls, and passing the arguments directly to the docker CLI tool. Perhaps it's better to not be involved at the build stage in that case, and instead attach to a running container, but this leaves the question of how we preprocess a Dockerfile that contains livepush directives.
A possible way of doing this:
livepush process Dockerfile | docker build . -f -
That is, have livepush process the dockerfile, and Docker read it from stdin. The user would start the container as normal, and then do a livepush attach <containerid>.
More UX thought is needed before we move forward with this feature.
Depends on: #75 and #76
Add a binary which people can use, like so:
which will either attach to a running container, or build another and begin the livepush process. This will allow greater adoption, as it won't require any further integration.
The text was updated successfully, but these errors were encountered: