Deploy Path-Based Local Dependencies

Example

dependencies:

- name: component-1

source:

path: ./different/component-1

- name: component-2

source:

path: ./different/component-2

deployments:

- name: use-dependency-image

helm:

componentChart: true

values:

containers:

- image: image(component-1.image1):tag(component-1.image1)

source

source.path

The source.path option expects a string with a relative path to a folder that contains a devspace.yaml which marks a project that is a dependency of the project referencing it.

Example: Local Project as Dependency

dependencies:

- source:

path: ../other-project

- source:

path: ./different/subproject

Explanation:

• Whenever you run devspace deploy or devspace dev, DevSpace will:
  • Load the devspace.yaml files of both dependencies and resolve their dependencies respectively.
  • Deploy both projects according to their devspace.yaml files.

General Options

profile

The profile option expects a string with the name of a profile defined in the devspace.yaml of this dependency. When configuring this option, this profile will be used to deploy the dependency, i.e. the dependency will be deployed similar to running devspace deploy -p [profile] within the folder of the dependency.

Example: Use Config Profile for Dependency

dependencies:

- source:

git: https://github.com/my-api-server

profile: production

skipBuild

The skipBuild option expects a boolean that defines if the image building process should be skipped when deploying this dependency. This is often useful if you rather want to use the tags that are defined in the deployment files (e.g. manifests or helm charts) which may reference more stable, production-like versions of the images.

info

Using skipBuild is useful when trying to speed up the dependency deployment process, especially when working with many dependencies that frequently change.

Default Value For skipBuild

skipBuild: false

Example: Skip Build for Dependency

dependencies:

- source:

git: https://github.com/my-api-server

skipBuild: true

ignoreDependencies

The ignoreDependencies option expects a boolean that defines if the dependencies of this dependencies should not be resolved and deployed.

info

Using ignoreDependencies can be useful to prevent problematic circular dependencies.

Default Value For ignoreDependencies

ignoreDependencies: false

Example: Ignore Dependencies of Dependency

dependencies:

- source:

git: https://github.com/my-api-server

ignoreDependencies: true

name

The name option is optional and expects a string stating the name of this dependency.

note

Adding a name for a dependency makes it possible to reference the dependency using flags, e.g.

devspace deploy --dependency=[name]

devspace purge --dependency=[name]

devspace render --dependency=[name]

namespace

The namespace option is optional and expects a string stating a namespace that should be used to deploy the dependency to.

note

By default, DevSpace deploys project dependencies in the same namespace as the project itself.

info

You should only use the namespace option if you are an advanced user because using this option requires any user that deploys this project to be able to create this namespace during the deployment process or to have access to the namespace with the current kube-context, if the namespace already exists.

vars

The vars option expects an array of objects with name and value of variables defined in the devspace.yaml of this dependency. When configuring this option, the variables will be overriden similar to passing variables via the --var flag to devspace. It is also useful to deploy the same dependency multiple times with just small adjustments.

Example: Override Config Vars for Dependency

# This will deploy the api server two times with

# different variable configurations

dependencies:

- source:

git: https://github.com/my-api-server

vars:

- name: NAME

value: api-server-1

- source:

git: https://github.com/my-api-server

vars:

- name: NAME

value: api-server-2

dev

The dev option allows you to reuse certain parts of a dependencies dev configuration.

note

If dev configuration is reused this will be merged into the top-level devspace.yaml and executed after image building and deployment

Example: Override Config Vars for Dependency

# This will use the dev.ports configuration of the dependency

# component-1

dependencies:

- source:

path: component-1

dev:

ports: true

dev.ports

If enabled will reuse the dependency's dev.ports configuration.

dev.sync

If enabled will reuse the dependency's dev.sync configuration. The base path of the sync configurations reused from a dependency is the folder where the dependency is saved in and not the current working directory.