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 28, 2024. It is now read-only.
I think the most natural expectation for a command named kaiser login is to get a shell on a container. It however just executes a command and to get the shell you have to run kaiser login sh.
I believe it's better to split this into two commands:
kaiser exec to run commands.
kaiser login to get a shell. This would be equivalent to running kaiser exec sh
While we're at it, we might want to add a parameter to specify which container we want to do this against. Currently it's hard coded to the app container and I this should remain the default but perhaps a parameter like the following is a good idea?
kaiser exec uptime #runs uptime on the app container
kaiser exec -c db uptime #runs uptime on the db container
kaiser login # gets us a shell on the app container
kaiser login -c db #gets us a shell on the db container
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I think the most natural expectation for a command named
kaiser login
is to get a shell on a container. It however just executes a command and to get the shell you have to runkaiser login sh
.I believe it's better to split this into two commands:
kaiser exec
to run commands.kaiser login
to get a shell. This would be equivalent to runningkaiser exec sh
While we're at it, we might want to add a parameter to specify which container we want to do this against. Currently it's hard coded to the app container and I this should remain the default but perhaps a parameter like the following is a good idea?
The text was updated successfully, but these errors were encountered: