Files
komodo/docsite/docs/file-paths.md
Maxwell Becker 5fc0a87dea 1.14 - Rename to Komodo - Docker Management (#56)
* setup network page

* add Network, Image, Container

* Docker ListItems and Inspects

* frontend build

* dev0

* network info working

* fix cargo lock

* dev1

* pages for the things

* implement Active in dashboard

* RunBuild update trigger list refresh

* rename deployment executions to StartDeployment etc

* add server level container control

* dev2

* add Config field to Image

* can get image labels from Config.Labels

* mount container page

* server show resource count

* add GetContainerLog api

* add _AllContainers api

* dev3

* move ResourceTarget to entities mod

* GetResourceMatchingContainer api

* connect container to resource

* dev4 add volume names to container list items

* ts types

* volume / image / network unused management

* add image history to image page

* fix PruneContainers incorret Operation

* update cache for server for server after server actions

* dev5

* add singapore to Hetzner

* implement delete single network / image / volume api

* dev6

* include "in use" on Docker Lists

* add docker resource delete buttons

* is nice

* fix volume all in use

* remove google font dependency

* use host networking in test compose

* implement Secret Variables (hidden in logs)

* remove unneeded borrow

* interpolate variables / secrets into extra args / onclone / onpull / command etc

* validate empty strings before SelectItem

* rename everything to Komodo

* rename workspace to komodo

* rc1
2024-09-01 15:38:40 -07:00

1.7 KiB

File Paths

When working with Komodo, you might have to configure file or directory paths.

Relative Paths

Where possible, it is better to use relative file paths. Using relative file paths removes the connection between the process being run and the particular server it runs on, making it easier to move things between servers.

Where you see relative paths:

  • setting the build directory and path of the Dockerfile
  • setting a pre build command path

For all of the above, the path can be given relative to the root of the configured repo

The one exception is the Dockerfile path, which is given relative to the build directory (This is done by Docker itself, and this pattern matches usage of the Docker CLI).

There are 3 kinds of paths to pass:

  1. to specify the root of the repo, use . as the path
  2. to specify a folder in the repo, pass it with no preceding /. For example, example_folder or folder1/folder2
  3. to specify an absolute path on the servers filesystem, use a preceding slash, eg. /home/ubuntu/example. This way should only be used if absolutely necessary, like when passing host paths when configuring docker volumes.

Implementation

Relative file paths are joined with the path of the repo on the system using a Rust PathBuf.

Docker Volume Paths

These are passed directly to the Docker CLI using --volume /path/on/system:/path/in/container. So for these, the same rules apply as when using Docker on the command line. Paths here should usually be given as absolute. It's also probably best to avoid usage of ~ or environment variables like $HOME, as this may lead to unexpected behavior.