Deploy Git-based Dependencies

Example

dependencies:
- name: api-server
  source:
    git: https://github.com/my-api-server
    branch: stable
  dev:
    sync: true
- name: auth-server
  source:
    git: https://github.com/my-auth-server
    revision: c967392
  profile: production
- name: database-server
  source:
    git: https://github.com/my-database-server
    tag: v3.0.1
    subPath: /configuration
  dev:
    ports: true
dev:
  terminal:
    imageSelector: ${runtime.dependencies.api-server.images.server-image}

Authentication

DevSpace is using the git credential store. So, if you are able to clone or pull from the specified repository, DevSpace will also be able clone or pull this repository.

source

source.git

The source.git option expects a string with the URL of a git repository. DevSpace will use the master branch by default and assumes that the devspace.yaml is located at the root directory of the git repository. To customize this behavior, use the following, complementary config options:

• branch for a different git branch
• tag for a specific git tag or release
• revision for a specific git commit hash
• subPath for custom location of devspace.yaml within the repository

Caching

DevSpace will clone the git repository which is defined as a dependency and cache the project in the global cache folder (i.e. $HOME/.devspace). DevSpace will also pull new commits before deploying the dependency.

Example: Git Projects as Dependency

dependencies:
- source:
    git: https://github.com/my-api-server
    branch: stable
- source:
    git: https://github.com/my-auth-server
    revision: c967392
- source:
    git: https://github.com/my-auth-server
    tag: v3.0.1

Explanation:

• When you run devspace deploy or devspace dev for the first time after defining the dependencies, DevSpace will check out all git projects into the global cache folder $HOME/.devspace.
• Whenever you run devspace deploy or devspace dev (even the first time), DevSpace will:
  • Run a git pull for all cached repositories.
  • Load the devspace.yaml files of the dependency projects and resolve their dependencies respectively.
  • Deploy all dependency projects according to their devspace.yaml files.

source.branch

The source.branch option expects a string stating the branch of the git repository referenced via source.git that should be used when deploying this dependency.

Default Value For source.branch

branch: master

source.tag

The source.tag option expects a string stating a tag of the git repository referenced via source.git that should be used when deploying this dependency.

source.revision

The source.revision option expects a string stating a commit hash of the git repository referenced via source.git that should be used when deploying this dependency.

source.subPath

The source.subPath option expects a string stating a folder within the git repository referenced via source.git that contains the devspace.yaml for this dependency.

Default Value For source.subPath

subPath: /

source.configName

The source.configName option is optional and specifies the dependency's DevSpace configuration file name within the git repository's source.subPath folder.

Default Value For source.configName

configName: devspace.yaml

Example: Use dev.yaml for Dependency's DevSpace Configuration

# This will use the file dev.yaml for the dependency's DevSpace configuration
# at the root folder of the repository's "stable" branch
dependencies:
- source:
    git: https://github.com/my-api-server
    branch: stable
    configName: dev.yaml

Git Options

source.disableShallow

The source.disableShallow option expects a boolean that prevents DevSpace from using shallow clones (git flag --depth 1) when retrieving a dependency via git clone.

Shallow Clone By Default

DevSpace uses shallow clones of git dependencies which reduces the time to retrieve the dependency.

Default Value For source.disableShallow

disableShallow: false

source.cloneArgs

The source.cloneArgs option expects an array of additional arguments that DevSpace will pass when cloning a git dependency using the git clone command.

Default Value For source.cloneArgs

cloneArgs: []

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

overwriteVars

The overwriteVars option is optional and expects a boolean. If this option is enabled it will overwrite all defined variables within the dependency config with the values of the variables defined in the base config. Variables that are not used or not defined within the base config aren't overwritten in the dependency config.

For example:

# devspace.yaml
vars:
- name: DEFINED_AND_USED
  value: my-base-value
- name: DEFINED_AND_NOT_USED
  value: my-other-base-value
dependencies:
- name: dep1
  source:
    path: dep1
  overwriteVars: true
  # If overwriteVars is true, all variables that are used within this
  # config are passed to the dependency and will overwrite the values of variables with 
  # the same name there. In this case only the variable DEFINED_AND_USED
  # will be passed to the dependency, as DEFINED_AND_NOT_USED is not used within the config.
  # overwriteVars: true
  #
  # If you want to pass the variable DEFINED_AND_NOT_USED to the dependency as well,
  # you can either use it somewhere within the config or explicitly pass it to the dependency with vars.
  # vars:
  # - name: DEFINED_AND_NOT_USED
  #   value: ${DEFINED_AND_NOT_USED}
deployments:
- name: deployment
  helm:
    componentChart: true
    values:
      containers:
      - image: ${DEFINED_AND_USED}

and

# dep1/devspace.yaml
vars:
- name: DEFINED_AND_USED
  value: my-dep-value
- name: DEFINED_AND_NOT_USED
  value: my-other-dep-value
deployments:
  # This will be my-other-dep-value
- name: ${DEFINED_AND_NOT_USED}
  helm:
    componentChart: true
    values:
      containers:
        # This will be my-base-value
      - image: ${DEFINED_AND_USED}

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.

dev.replacePods

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