CLI Reference
In this section you will learn about:
-
ways to configure
ike(through flags, files et al.) -
complete list of commands, and their available flags
Autocomplete
If you are using zsh or bash you can easily enable autocomplete for ike by invoking . <(ike completion SHELL).
Configuration
There are several ways to configure ike commands:
-
Flags
-
Environment variables
-
Configuration file
Each item takes precedence over the item below it.
Environment variables are prefixed with IKE and have fully qualified names, for example
in case of develop command and its port flag corresponding environment variable is
IKE_DEVELOP_PORT.
Each of the commands can be persisted in the configuration file with all their flags respectively.
In case of develop command yaml file could look like:
develop:
deployment: test
run: "java -jar config.jar"
port: 9876
See ike root command to learn about the global config flag and available formats.
Below you can find a documented list of all commands and their available flags.
Available commands
ike
Main command, which holds global flags and prints the overall usage of the tool.
| Option | Purpose | Format | Default |
|---|---|---|---|
|
config file (supported formats: json, toml, yaml, yml, properties, props, prop, hcl, tfvars, dotenv, env, ini) |
|
|
|
prints the version number of ike cli |
|
|
ike create
Creates or joins existing development session in the cluster. Allows to re-route cluster network traffic to your local process.
The create command requires an image-reference to a repository which is reachable from within the cluster. It will prepare a session with the given image.
The create command will exit and leave the Session alive in the cluster as soon as it’s created.
|
| Option | Purpose | Format | Default |
|---|---|---|---|
|
name of the deployment or deployment config |
|
|
|
create a prepared session with the given image |
|
|
|
return result in json |
|
|
|
target namespace to develop against (defaults to default for the current context) |
|
|
|
specifies traffic route options in the format of type:name=value. Defaults to X-Workspace-Route header with current session name value |
|
|
|
create or join an existing session |
|
ike delete
Deletes or leaves existing development session in the cluster.
| Option | Purpose | Format | Default |
|---|---|---|---|
|
name of the deployment or deployment config |
|
|
|
target namespace to develop against (defaults to default for the current context) |
|
|
|
create or join an existing session |
|
ike develop
Creates or joins existing development session in the cluster. Allows to re-route cluster network traffic to your local process.
| Option | Purpose | Format | Default |
|---|---|---|---|
|
command to build your application before run |
|
|
|
name of the deployment or deployment config |
|
|
|
telepresence proxying mode - see https://www.telepresence.io/reference/methods |
|
|
|
target namespace to develop against (defaults to default for the current context) |
|
|
|
always skips build |
|
|
|
list of ports to be exposed in format local[:remote]. |
repeat flag and/or comma-separated list of strings |
|
|
specifies traffic route options in the format of type:name=value. Defaults to X-Workspace-Route header with current session name value |
|
|
|
command to run your application |
|
|
|
create or join an existing session |
|
|
|
enables watch |
|
|
|
list of patterns to exclude (always excludes [*.log .git/]) |
repeat flag and/or comma-separated list of strings |
|
|
list of directories to watch (relative to the one from which ike has been started) |
repeat flag and/or comma-separated list of strings |
|
Watching for changes
ike develop provides --watch functionality to trigger build and relaunch the process whenever you modify something
in your project. This way you can immediately introduce your changes in your cluster.
By default, all log files (*.log) and .git folder are not monitored.
| For details on how define what should be watched see ike develop reference. |
If you have .gitignore in the root directory, from where ike has been started, rules defined in this file
are also respected.
Have a look at official Git documentation to learn more about the .gitignore format.
|
Only root .gitignore is handled. If you happen to have additional .gitignore files in subdirectories
those won’t be respected.
|