Import Other devspace.yaml Files

Importing other devspace.yaml files is a powerful way to standardize things across multiple projects. Common use cases include:

• Importing a library of custom functions that should be available in each project
• Importing a set of standardized pipelines to make the devspace dev behavior consistent across a set of projects
• Importing a set of custom commands that should be available for engineers in similar project (e.g. you want that all Java Spring Boot applications should provide a devspace run migrate-db command)

Example

Let's say we have a devspace.yaml in project-a with the following content:

File: github.com/project-a/devspace.yaml

version: v2beta1
imports:
- git: github.com/project-b.git
  tag: v1.2.0
- ...
functions:
  function_in_project_a_only: |-
    echo "This is a function only available in project a"

The devspace.yaml above imports the devspace.yaml from project-b which looks like this:

File: github.com/project-b/devspace.yaml

version: v2beta1
functions:
  shared_function: |-
    echo "This is a shared function"

If we run devspace print inside project-a, it will show the following merged config:

project-a/ $ devspace print

version: v2beta1
functions:
  shared_function: |-
    echo "This is a shared function"
  function_in_project_a_only: |-
    echo "This is a function only available in project a"

imports vs dependencies

The following table clarifies when to use imports and when to use dependencies:

Difference	imports	dependencies
Use Case	Importing shared/standardized functionality (e.g. functions, pipelines, commands) into independent projects	Defining logical dependencies between inter-dependent projects (app A requiring app B to be deployed)
Example	If projects A and B should both have some shared functionality that is defined in a shared devspace.yaml	If a project A with requires projects B and C to be deployed in order to work correctly
Impact	If project A imports a devspace.yaml from another devspace.yaml, then everything defined in this imported devspace.yaml will be merged into the devspace.yaml of project A.	If project A has a devspace.yaml that defines project B as a git-based dependency, then DevSpace will git clone project B and deploy it when you run run_dependency_pipelines b inside your pipeline script.

Naming Conflicts

If a project imports a devspace.yaml that defines a named object (e.g. function, pipeline, etc.), the main devspace.yaml that is defining the imports takes precedence over the imported devspace.yaml.

Let's assume the following devspace.yaml inside project-a:

File: github.com/project-a/devspace.yaml

version: v2beta1
imports:
- git: github.com/project-b.git
functions:
  function_x: |-
    echo "This is a function_x from project-a"

The devspace.yaml above imports the devspace.yaml from project-b which looks like this:

File: github.com/project-b/devspace.yaml

version: v2beta1
functions:
  function_x: |-
    echo "This is function_x from project-b"

If we run devspace print inside project-a, it will show the following merged config:

project-a/ $ devspace print

version: v2beta1
functions:
  function_x: |-
    echo "This is a function_x from project-a"

Import Sections

The following DevSpace config sections are allowed to be imported:

/require/*
/vars/*
/dev/*
/deployments/*
/images/*
/localRegistry/*
/pipelines/*
/commands/*
/functions/*
/pullSecrets/*
/dependencies/*
/profiles/*
/hooks/*

All other config sections will be ignored during import.

Config Reference

The imports section in your devspace.yaml file is an array and each entry (import) supports the following fields:

imports required object[]

Imports merges specified config files into this one. This is very useful to split up your DevSpace configuration into multiple files and reuse those through git, a remote url or common local path.

enabled required boolean true

Enabled specifies if the given import should be enabled

Source: Local Filesystem

path required string

Path is the local path where DevSpace can find the artifact. This option is mutually exclusive with the git option.

Source: Git Repository

git required string

Git is the remote repository to download the artifact from. You can either use https projects or ssh projects here, but need to make sure git can pull the project. This option is mutually exclusive with the path option.

subPath required string

SubPath is a path within the git repository where the artifact lies in

branch required string

Branch is the git branch to pull

tag required string

Tag is the tag to pull

revision required string

Revision is the git revision to pull

cloneArgs required string[]

CloneArgs are additional arguments that should be supplied to the git CLI

disableShallow required boolean false

DisableShallow can be used to turn off shallow clones as these are the default used by devspace

disablePull required boolean false

DisablePull will disable pulling every time DevSpace is reevaluating this source