v6.0.1-beta.2

What's Changed

• Fixed an issue where DevSpace had problems syncing single files by @FabianKramm in #2257
• Fixed an issue where DevSpace would always re-deploy charts imported using git by @lizardruss in #2244
• Fixed an issue where DevSpace wouldn't resolve environment variable vars correctly by @FabianKramm in #2249
• Fixed an issue where DevSpace incorrectly compared semantic versions. by @CiiDyR in #2250
• Fixed an issue where DevSpace commands were not usable in the DevSpace UI by @FabianKramm in #2251
• Fixed an issue where DevSpace would panic if there would be an empty pipeline, var, command, pullSecret or dev config by @FabianKramm in #2252
• Improved the output if a yaml parsing error occurs @FabianKramm in #2253
• Print error if reserved function name is used in config @FabianKramm in #2253
• Mention that path field can be a URL as well by @alexissellier in #2235
• Fixed an issue where DevSpace was not correctly authenticating to an OCI registry if chart.username and chart.password were provided by @FabianKramm in #2240
• Fixed an issue where DevSpace would spawn many subprocesses if devspace was used as part of a DevSpace variable by @FabianKramm in #2240

New Contributors

• @alexissellier made their first contribution in #2235

Full Changelog: v6.0.0...v6.0.1-beta.2

v6.0.1-beta.1

What's Changed

• Fixed an issue where DevSpace would always re-deploy charts imported using git by @lizardruss in #2244
• Fixed an issue where DevSpace wouldn't resolve environment variable vars correctly by @FabianKramm in #2249
• Fixed an issue where DevSpace incorrectly compared semantic versions. by @CiiDyR in #2250
• Fixed an issue where DevSpace commands were not usable in the DevSpace UI by @FabianKramm in #2251
• Fixed an issue where DevSpace would panic if there would be an empty pipeline, var, command, pullSecret or dev config by @FabianKramm in #2252
• Improved the output if a yaml parsing error occurs @FabianKramm in #2253
• Print error if reserved function name is used in config @FabianKramm in #2253
• Mention that path field can be a URL as well by @alexissellier in #2235
• Fixed an issue where DevSpace was not correctly authenticating to an OCI registry if chart.username and chart.password were provided by @FabianKramm in #2240
• Fixed an issue where DevSpace would spawn many subprocesses if devspace was used as part of a DevSpace variable by @FabianKramm in #2240

New Contributors

• @alexissellier made their first contribution in #2235

Full Changelog: v6.0.0...v6.0.1-beta.1

v6.0.1-beta.0

What's Changed

• Mention that path field can be a URL as well by @alexissellier in #2235

• Fixed an issue where DevSpace was not correctly authenticating to an OCI registry if chart.username and chart.password were provided by @FabianKramm in #2240
• Fixed an issue where DevSpace would spawn many subprocesses if devspace was used as part of a DevSpace variable by @FabianKramm in #2240

New Contributors

• @alexissellier made their first contribution in #2235

Full Changelog: v6.0.0...v6.0.1-beta.0

v6.0.0

Config Version v2beta1

With v6 a new config version v2beta1 was introduced, that restructures many parts of the DevSpace config, such as deployments, dev, commands and vars. Older config versions are still supported and will be converted automatically in memory by DevSpace to this new version. To see how the old config got converted, run devspace print, which can be a starting point on how to convert your older DevSpace config.

Pipelines

DevSpace used a declarative approach to define its dev, build, deploy and purge pipeline, however we felt most of it was hardcoded and difficult to change. We introduced hooks to make these pipelines more adjustable, however in many cases this was difficult to understand as the pipeline was still implicit and through hooks scattered around the devspace.yaml.

With DevSpace v6 we introduce a pipelines concept that allows you to override DevSpace default behaviour and create more dynamic and powerful pipelines compared to what DevSpace offers you as a default. These pipelines are written similar to github actions and DevSpace provides custom commands that allow you to build images, deploy deployments as well as stop and start development. This also allows you to define concurrency a lot easier, so from now on you can easily build, deploy or start development in parallel as you desire.

Example: Simple Procedural Pipeline

With pipelines you can decide if to use the declarative approach or define objects on the fly with the --set flag. A simple project that deploys an alpine container and then starts syncing to it can be purely written in the new pipeline form:

version: v2beta1
name: my-project
pipelines:
  # Override the default devspace dev behaviour
  dev:
    run: |-
      # Create a new deployment on the fly with an alpine container
      create_deployments my-simple --set helm.values.containers[0].image=alpine

      # Starts syncing local directory to /app in that container and open a terminal to it
      start_dev my-dev --set imageSelector=alpine \
                       --set sync[0].path=.:/app \
                       --set terminal.enabled=true

Example: Simple Declarative Pipeline

As configurations get more complex, you probably want to reuse config or define it in a separate place, here the declarative approach makes sense that you can reference in your pipeline:

version: v2beta1
name: my-project

vars:
  IMAGE: alpine

deployments:
  my-simple: ...
  my-other-deployment: ...
  dependent-deployment: ...

dev:
  my-dev: ...
  
commands:
  dev:
    run_watch -p devspace.yaml -- devspace run-pipeline dev

pipelines:
  common:
    run: |-
      # Deploy the deployments in parallel
      create_deployments my-simple my-other-deployment

      # Then deploy the dependent deployment
      create_deployments dependent-deployment
        
      # Starts my-dev configuration if devspace dev and enable terminal as well
      if is_command dev; then
        start_dev my-dev --set terminal.enabled=true
      fi
  deploy:
    run: |-
       # Run the pipeline common
      run_pipelines common
  dev:
    run: |-
      # Run the pipeline common
      run_pipelines common

Imports

You want DRY config and we heard you! With imports you can now merge different devspace.yaml's together and define your variables, deployments, commands and pipelines in a single repository or file and import them into other projects through git, urls or local paths. With the new pipelines you can then define what images to build, what deployments to deploy and what dev configurations to start and stop:

import.yaml

version: v2beta1
name: import1

vars:
  MY_IMPORTED_VAR: test

functions:
  my-function: echo ${MY_IMPORTED_VAR}

pipelines:
  print-var:
    run: |-
      my-function

devspace.yaml

version: v2beta1
name: main

imports:
- path: import.yaml
# Conditionally importing is also possible
- path: import2.yaml
  enabled: $(is_equal ${devspace.namespace} "test")

pipelines:
  dev:
    run: |-
       # will print 'test'
       run_pipelines print-var 

SSH & Proxy Commands

It is now possible to let DevSpace setup an SSH connection as well as proxy certain commands from the local host to the container:

name: devspace-project
dev:
  my-dev:
    imageSelector: nginx
    ssh:
      enabled: true
    proxyCommands:
    - command: git
    - command: devspace
    - command: kubectl

With the configuration above you can run the following (proxyCommands also works with terminal or kubectl exec):

ssh my-dev.devspace-project.devspace
# Run the following commands inside the container that are proxied to the local computer
$/ git 
$/ devspace 
$/ kubectl

!! Breaking Changes !!

DevSpace version 6 introduces some breaking changes to work efficiently with the new Pipelines feature. Almost all older devspace.yaml should still work as config is migrated automatically, however we removed some deprecated and older functionality that we felt is now either obsolete or unused.

Removed Flags:

• --deployments was removed, use pipeline logic instead
• --skip-pipeline in devspace dev was removed, use pipeline logic instead
• --verbose-dependencies and --skip-dependencies was removed and dependencies will be pulled every run
• --interactive was removed from devspace dev, use pipeline logic instead
• --parent-profile was removed, use multiple --profile flags instead
• --restore-vars, --vars-secret and --save-vars was removed. Use vars.MY_VAR.remote: true instead
• --verbose-sync was removed, use --debug instead
• --exit-after-deploy, --terminal-reconnect, --portforwarding and --sync was removed
• --wait, --timeout was removed, use pipeline logic instead
• --container-path and --local-path were removed from devspace sync, please use --path instead

Removed dev.autoReload

This functionality was removed from DevSpace and will be replaced in future by automatically reloading pipelines

DevSpace will no longer ask for undefined variables

If you are using a variable like this, DevSpace will not ask anymore for its value:

deployments:
- name: ...
   helm:
    values:
      key: ${VARIABLE}

rather change it to

vars:
- name: VARIABLE

deployments:
- name: ...
   helm:
    values:
      key: ${VARIABLE}

Dependency names must be unique

DevSpace determines which dependency was deployed now solely based on the name, so multiple dependencies or nested dependencies with the same name will be resolved as the same dependency and deployed only once.

Other Breaking Changes

• Removed devspace use profile instead use profile activation instead
• Removed dependencies[*].skipBuild
• Removed dev.sync[*].onDownload
• Removed deployments[*].helm.driver, deployments[*].helm.deleteArgs, deployments[*].kubectl.deleteArgs and deployments[*].helm.path
• Removed deployments[*].helm.v2
• Dependencies are now purged after deployments are deleted instead of before
• Variables in commands will be resolved by default now
• devspace dev is not taking any arguments anymore

Many other changes!

There are many other improvements and changes that went into this new DevSpace version. We'll release full exhaustive release notes soon.

v6.0.0-beta.10

Config Version v2beta1

With v6 a new config version v2beta1 was introduced, that restructures many parts of the DevSpace config, such as deployments, dev, commands and vars. Older config versions are still supported and will be converted automatically in memory by DevSpace to this new version. To see how the old config got converted, run devspace print, which can be a starting point on how to convert your older DevSpace config.

Pipelines

DevSpace used a declarative approach to define its dev, build, deploy and purge pipeline, however we felt most of it was hardcoded and difficult to change. We introduced hooks to make these pipelines more adjustable, however in many cases this was difficult to understand as the pipeline was still implicit and through hooks scattered around the devspace.yaml.

With DevSpace v6 we introduce a pipelines concept that allows you to override DevSpace default behaviour and create more dynamic and powerful pipelines compared to what DevSpace offers you as a default. These pipelines are written similar to github actions and DevSpace provides custom commands that allow you to build images, deploy deployments as well as stop and start development. This also allows you to define concurrency a lot easier, so from now on you can easily build, deploy or start development in parallel as you desire.

Example: Simple Procedural Pipeline

With pipelines you can decide if to use the declarative approach or define objects on the fly with the --set flag. A simple project that deploys an alpine container and then starts syncing to it can be purely written in the new pipeline form:

version: v2beta1
name: my-project
pipelines:
  # Override the default devspace dev behaviour
  dev:
    run: |-
      # Create a new deployment on the fly with an alpine container
      create_deployments my-simple --set helm.values.containers[0].image=alpine

      # Starts syncing local directory to /app in that container and open a terminal to it
      start_dev my-dev --set imageSelector=alpine \
                       --set sync[0].path=.:/app \
                       --set terminal.enabled=true

Example: Simple Declarative Pipeline

As configurations get more complex, you probably want to reuse config or define it in a separate place, here the declarative approach makes sense that you can reference in your pipeline:

version: v2beta1
name: my-project

vars:
  IMAGE: alpine

deployments:
  my-simple: ...
  my-other-deployment: ...
  dependent-deployment: ...

dev:
  my-dev: ...
  
commands:
  dev:
    run_watch -p devspace.yaml -- devspace run-pipeline dev

pipelines:
  common:
    run: |-
      # Deploy the deployments in parallel
      create_deployments my-simple my-other-deployment

      # Then deploy the dependent deployment
      create_deployments dependent-deployment
        
      # Starts my-dev configuration if devspace dev and enable terminal as well
      if is_command dev; then
        start_dev my-dev --set terminal.enabled=true
      fi
  deploy:
    run: |-
       # Run the pipeline common
      run_pipelines common
  dev:
    run: |-
      # Run the pipeline common
      run_pipelines common

Imports

You want DRY config and we heard you! With imports you can now merge different devspace.yaml's together and define your variables, deployments, commands and pipelines in a single repository or file and import them into other projects through git, urls or local paths. With the new pipelines you can then define what images to build, what deployments to deploy and what dev configurations to start and stop:

import.yaml

version: v2beta1
name: import1

vars:
  MY_IMPORTED_VAR: test

functions:
  my-function: echo ${MY_IMPORTED_VAR}

pipelines:
  print-var:
    run: |-
      my-function

devspace.yaml

version: v2beta1
name: main

imports:
- path: import.yaml
# Conditionally importing is also possible
- path: import2.yaml
  enabled: $(is_equal ${devspace.namespace} "test")

pipelines:
  dev:
    run: |-
       # will print 'test'
       run_pipelines print-var 

SSH & Proxy Commands

It is now possible to let DevSpace setup an SSH connection as well as proxy certain commands from the local host to the container:

name: devspace-project
dev:
  my-dev:
    imageSelector: nginx
    ssh:
      enabled: true
    proxyCommands:
    - command: git
    - command: devspace
    - command: kubectl

With the configuration above you can run the following (proxyCommands also works with terminal or kubectl exec):

ssh my-dev.devspace-project.devspace
# Run the following commands inside the container that are proxied to the local computer
$/ git 
$/ devspace 
$/ kubectl

!! Breaking Changes !!

DevSpace version 6 introduces some breaking changes to work efficiently with the new Pipelines feature. Almost all older devspace.yaml should still work as config is migrated automatically, however we removed some deprecated and older functionality that we felt is now either obsolete or unused.

Removed Flags:

• --deployments was removed, use pipeline logic instead
• --skip-pipeline in devspace dev was removed, use pipeline logic instead
• --verbose-dependencies and --skip-dependencies was removed and dependencies will be pulled every run
• --interactive was removed from devspace dev, use pipeline logic instead
• --parent-profile was removed, use multiple --profile flags instead
• --restore-vars, --vars-secret and --save-vars was removed. Use vars.MY_VAR.remote: true instead
• --verbose-sync was removed, use --debug instead
• --exit-after-deploy, --terminal-reconnect, --portforwarding and --sync was removed
• --wait, --timeout was removed, use pipeline logic instead
• --container-path and --local-path were removed from devspace sync, please use --path instead

Removed dev.autoReload

This functionality was removed from DevSpace and will be replaced in future by automatically reloading pipelines

DevSpace will no longer ask for undefined variables

If you are using a variable like this, DevSpace will not ask anymore for its value:

deployments:
- name: ...
   helm:
    values:
      key: ${VARIABLE}

rather change it to

vars:
- name: VARIABLE

deployments:
- name: ...
   helm:
    values:
      key: ${VARIABLE}

Dependency names must be unique

DevSpace determines which dependency was deployed now solely based on the name, so multiple dependencies or nested dependencies with the same name will be resolved as the same dependency and deployed only once.

Other Breaking Changes

• Removed devspace use profile instead use profile activation instead
• Removed dependencies[*].skipBuild
• Removed dev.sync[*].onDownload
• Removed deployments[*].helm.driver, deployments[*].helm.deleteArgs, deployments[*].kubectl.deleteArgs and deployments[*].helm.path
• Removed deployments[*].helm.v2
• Dependencies are now purged after deployments are deleted instead of before
• Variables in commands will be resolved by default now
• devspace dev is not taking any arguments anymore

Many other changes!

There are many other improvements and changes that went into this new DevSpace version. We'll release full exhaustive release notes soon.

v6.0.0-beta.9

Config Version v2beta1

With v6 a new config version v2beta1 was introduced, that restructures many parts of the DevSpace config, such as deployments, dev, commands and vars. Older config versions are still supported and will be converted automatically in memory by DevSpace to this new version. To see how the old config got converted, run devspace print, which can be a starting point on how to convert your older DevSpace config.

Pipelines

DevSpace used a declarative approach to define its dev, build, deploy and purge pipeline, however we felt most of it was hardcoded and difficult to change. We introduced hooks to make these pipelines more adjustable, however in many cases this was difficult to understand as the pipeline was still implicit and through hooks scattered around the devspace.yaml.

With DevSpace v6 we introduce a pipelines concept that allows you to override DevSpace default behaviour and create more dynamic and powerful pipelines compared to what DevSpace offers you as a default. These pipelines are written similar to github actions and DevSpace provides custom commands that allow you to build images, deploy deployments as well as stop and start development. This also allows you to define concurrency a lot easier, so from now on you can easily build, deploy or start development in parallel as you desire.

Example: Simple Procedural Pipeline

With pipelines you can decide if to use the declarative approach or define objects on the fly with the --set flag. A simple project that deploys an alpine container and then starts syncing to it can be purely written in the new pipeline form:

version: v2beta1
name: my-project
pipelines:
  # Override the default devspace dev behaviour
  dev:
    run: |-
      # Create a new deployment on the fly with an alpine container
      create_deployments my-simple --set helm.values.containers[0].image=alpine

      # Starts syncing local directory to /app in that container and open a terminal to it
      start_dev my-dev --set imageSelector=alpine \
                       --set sync[0].path=.:/app \
                       --set terminal.enabled=true

Example: Simple Declarative Pipeline

As configurations get more complex, you probably want to reuse config or define it in a separate place, here the declarative approach makes sense that you can reference in your pipeline:

version: v2beta1
name: my-project

vars:
  IMAGE: alpine

deployments:
  my-simple: ...
  my-other-deployment: ...
  dependent-deployment: ...

dev:
  my-dev: ...
  
commands:
  dev:
    run_watch -p devspace.yaml -- devspace run-pipeline dev

pipelines:
  common:
    run: |-
      # Deploy the deployments in parallel
      create_deployments my-simple my-other-deployment

      # Then deploy the dependent deployment
      create_deployments dependent-deployment
        
      # Starts my-dev configuration if devspace dev and enable terminal as well
      if is_command dev; then
        start_dev my-dev --set terminal.enabled=true
      fi
  deploy:
    run: |-
       # Run the pipeline common
      run_pipelines common
  dev:
    run: |-
      # Run the pipeline common
      run_pipelines common

Imports

You want DRY config and we heard you! With imports you can now merge different devspace.yaml's together and define your variables, deployments, commands and pipelines in a single repository or file and import them into other projects through git, urls or local paths. With the new pipelines you can then define what images to build, what deployments to deploy and what dev configurations to start and stop:

import.yaml

version: v2beta1
name: import1

vars:
  MY_IMPORTED_VAR: test

functions:
  my-function: echo ${MY_IMPORTED_VAR}

pipelines:
  print-var:
    run: |-
      my-function

devspace.yaml

version: v2beta1
name: main

imports:
- path: import.yaml
# Conditionally importing is also possible
- path: import2.yaml
  enabled: $(is_equal ${devspace.namespace} "test")

pipelines:
  dev:
    run: |-
       # will print 'test'
       run_pipelines print-var 

SSH & Proxy Commands

It is now possible to let DevSpace setup an SSH connection as well as proxy certain commands from the local host to the container:

name: devspace-project
dev:
  my-dev:
    imageSelector: nginx
    ssh:
      enabled: true
    proxyCommands:
    - command: git
    - command: devspace
    - command: kubectl

With the configuration above you can run the following (proxyCommands also works with terminal or kubectl exec):

ssh my-dev.devspace-project.devspace
# Run the following commands inside the container that are proxied to the local computer
$/ git 
$/ devspace 
$/ kubectl

!! Breaking Changes !!

DevSpace version 6 introduces some breaking changes to work efficiently with the new Pipelines feature. Almost all older devspace.yaml should still work as config is migrated automatically, however we removed some deprecated and older functionality that we felt is now either obsolete or unused.

Removed Flags:

• --deployments was removed, use pipeline logic instead
• --skip-pipeline in devspace dev was removed, use pipeline logic instead
• --verbose-dependencies and --skip-dependencies was removed and dependencies will be pulled every run
• --interactive was removed from devspace dev, use pipeline logic instead
• --parent-profile was removed, use multiple --profile flags instead
• --restore-vars, --vars-secret and --save-vars was removed. Use vars.MY_VAR.remote: true instead
• --verbose-sync was removed, use --debug instead
• --exit-after-deploy, --terminal-reconnect, --portforwarding and --sync was removed
• --wait, --timeout was removed, use pipeline logic instead
• --container-path and --local-path were removed from devspace sync, please use --path instead

Removed dev.autoReload

This functionality was removed from DevSpace and will be replaced in future by automatically reloading pipelines

DevSpace will no longer ask for undefined variables

If you are using a variable like this, DevSpace will not ask anymore for its value:

deployments:
- name: ...
   helm:
    values:
      key: ${VARIABLE}

rather change it to

vars:
- name: VARIABLE

deployments:
- name: ...
   helm:
    values:
      key: ${VARIABLE}

Dependency names must be unique

DevSpace determines which dependency was deployed now solely based on the name, so multiple dependencies or nested dependencies with the same name will be resolved as the same dependency and deployed only once.

Other Breaking Changes

• Removed devspace use profile instead use profile activation instead
• Removed dependencies[*].skipBuild
• Removed dev.sync[*].onDownload
• Removed deployments[*].helm.driver, deployments[*].helm.deleteArgs, deployments[*].kubectl.deleteArgs and deployments[*].helm.path
• Removed deployments[*].helm.v2
• Dependencies are now purged after deployments are deleted instead of before
• Variables in commands will be resolved by default now
• devspace dev is not taking any arguments anymore

Many other changes!

There are many other improvements and changes that went into this new DevSpace version. We'll release full exhaustive release notes soon.

v6.0.0-beta.8

Config Version v2beta1

With v6 a new config version v2beta1 was introduced, that restructures many parts of the DevSpace config, such as deployments, dev, commands and vars. Older config versions are still supported and will be converted automatically in memory by DevSpace to this new version. To see how the old config got converted, run devspace print, which can be a starting point on how to convert your older DevSpace config.

Pipelines

DevSpace used a declarative approach to define its dev, build, deploy and purge pipeline, however we felt most of it was hardcoded and difficult to change. We introduced hooks to make these pipelines more adjustable, however in many cases this was difficult to understand as the pipeline was still implicit and through hooks scattered around the devspace.yaml.

With DevSpace v6 we introduce a pipelines concept that allows you to override DevSpace default behaviour and create more dynamic and powerful pipelines compared to what DevSpace offers you as a default. These pipelines are written similar to github actions and DevSpace provides custom commands that allow you to build images, deploy deployments as well as stop and start development. This also allows you to define concurrency a lot easier, so from now on you can easily build, deploy or start development in parallel as you desire.

Example: Simple Procedural Pipeline

With pipelines you can decide if to use the declarative approach or define objects on the fly with the --set flag. A simple project that deploys an alpine container and then starts syncing to it can be purely written in the new pipeline form:

version: v2beta1
name: my-project
pipelines:
  # Override the default devspace dev behaviour
  dev:
    run: |-
      # Create a new deployment on the fly with an alpine container
      create_deployments my-simple --set helm.values.containers[0].image=alpine

      # Starts syncing local directory to /app in that container and open a terminal to it
      start_dev my-dev --set imageSelector=alpine \
                       --set sync[0].path=.:/app \
                       --set terminal.enabled=true

Example: Simple Declarative Pipeline

As configurations get more complex, you probably want to reuse config or define it in a separate place, here the declarative approach makes sense that you can reference in your pipeline:

version: v2beta1
name: my-project

vars:
  IMAGE: alpine

deployments:
  my-simple: ...
  my-other-deployment: ...
  dependent-deployment: ...

dev:
  my-dev: ...
  
commands:
  dev:
    run_watch -p devspace.yaml -- devspace run-pipeline dev

pipelines:
  common:
    run: |-
      # Deploy the deployments in parallel
      create_deployments my-simple my-other-deployment

      # Then deploy the dependent deployment
      create_deployments dependent-deployment
        
      # Starts my-dev configuration if devspace dev and enable terminal as well
      if is_command dev; then
        start_dev my-dev --set terminal.enabled=true
      fi
  deploy:
    run: |-
       # Run the pipeline common
      run_pipelines common
  dev:
    run: |-
      # Run the pipeline common
      run_pipelines common

Imports

You want DRY config and we heard you! With imports you can now merge different devspace.yaml's together and define your variables, deployments, commands and pipelines in a single repository or file and import them into other projects through git, urls or local paths. With the new pipelines you can then define what images to build, what deployments to deploy and what dev configurations to start and stop:

import.yaml

version: v2beta1
name: import1

vars:
  MY_IMPORTED_VAR: test

functions:
  my-function: echo ${MY_IMPORTED_VAR}

pipelines:
  print-var:
    run: |-
      my-function

devspace.yaml

version: v2beta1
name: main

imports:
- path: import.yaml
# Conditionally importing is also possible
- path: import2.yaml
  enabled: $(is_equal ${devspace.namespace} "test")

pipelines:
  dev:
    run: |-
       # will print 'test'
       run_pipelines print-var 

SSH & Proxy Commands

It is now possible to let DevSpace setup an SSH connection as well as proxy certain commands from the local host to the container:

name: devspace-project
dev:
  my-dev:
    imageSelector: nginx
    ssh:
      enabled: true
    proxyCommands:
    - command: git
    - command: devspace
    - command: kubectl

With the configuration above you can run the following (proxyCommands also works with terminal or kubectl exec):

ssh my-dev.devspace-project.devspace
# Run the following commands inside the container that are proxied to the local computer
$/ git 
$/ devspace 
$/ kubectl

!! Breaking Changes !!

DevSpace version 6 introduces some breaking changes to work efficiently with the new Pipelines feature. Almost all older devspace.yaml should still work as config is migrated automatically, however we removed some deprecated and older functionality that we felt is now either obsolete or unused.

Removed Flags:

• --deployments was removed, use pipeline logic instead
• --skip-pipeline in devspace dev was removed, use pipeline logic instead
• --verbose-dependencies and --skip-dependencies was removed and dependencies will be pulled every run
• --interactive was removed from devspace dev, use pipeline logic instead
• --parent-profile was removed, use multiple --profile flags instead
• --restore-vars, --vars-secret and --save-vars was removed. Use vars.MY_VAR.remote: true instead
• --verbose-sync was removed, use --debug instead
• --exit-after-deploy, --terminal-reconnect, --portforwarding and --sync was removed
• --wait, --timeout was removed, use pipeline logic instead
• --container-path and --local-path were removed from devspace sync, please use --path instead

Removed dev.autoReload

This functionality was removed from DevSpace and will be replaced in future by automatically reloading pipelines

DevSpace will no longer ask for undefined variables

If you are using a variable like this, DevSpace will not ask anymore for its value:

deployments:
- name: ...
   helm:
    values:
      key: ${VARIABLE}

rather change it to

vars:
- name: VARIABLE

deployments:
- name: ...
   helm:
    values:
      key: ${VARIABLE}

Dependency names must be unique

DevSpace determines which dependency was deployed now solely based on the name, so multiple dependencies or nested dependencies with the same name will be resolved as the same dependency and deployed only once.

Other Breaking Changes

• Removed devspace use profile instead use profile activation instead
• Removed dependencies[*].skipBuild
• Removed dev.sync[*].onDownload
• Removed deployments[*].helm.driver, deployments[*].helm.deleteArgs, deployments[*].kubectl.deleteArgs and deployments[*].helm.path
• Removed deployments[*].helm.v2
• Dependencies are now purged after deployments are deleted instead of before
• Variables in commands will be resolved by default now
• devspace dev is not taking any arguments anymore

Many other changes!

There are many other improvements and changes that went into this new DevSpace version. We'll release full exhaustive release notes soon.

v6.0.0-beta.7

Config Version v2beta1

With v6 a new config version v2beta1 was introduced, that restructures many parts of the DevSpace config, such as deployments, dev, commands and vars. Older config versions are still supported and will be converted automatically in memory by DevSpace to this new version. To see how the old config got converted, run devspace print, which can be a starting point on how to convert your older DevSpace config.

Pipelines

DevSpace used a declarative approach to define its dev, build, deploy and purge pipeline, however we felt most of it was hardcoded and difficult to change. We introduced hooks to make these pipelines more adjustable, however in many cases this was difficult to understand as the pipeline was still implicit and through hooks scattered around the devspace.yaml.

With DevSpace v6 we introduce a pipelines concept that allows you to override DevSpace default behaviour and create more dynamic and powerful pipelines compared to what DevSpace offers you as a default. These pipelines are written similar to github actions and DevSpace provides custom commands that allow you to build images, deploy deployments as well as stop and start development. This also allows you to define concurrency a lot easier, so from now on you can easily build, deploy or start development in parallel as you desire.

Example: Simple Procedural Pipeline

With pipelines you can decide if to use the declarative approach or define objects on the fly with the --set flag. A simple project that deploys an alpine container and then starts syncing to it can be purely written in the new pipeline form:

version: v2beta1
name: my-project
pipelines:
  # Override the default devspace dev behaviour
  dev:
    run: |-
      # Create a new deployment on the fly with an alpine container
      create_deployments my-simple --set helm.values.containers[0].image=alpine

      # Starts syncing local directory to /app in that container and open a terminal to it
      start_dev my-dev --set imageSelector=alpine \
                       --set sync[0].path=.:/app \
                       --set terminal.enabled=true

Example: Simple Declarative Pipeline

As configurations get more complex, you probably want to reuse config or define it in a separate place, here the declarative approach makes sense that you can reference in your pipeline:

version: v2beta1
name: my-project

vars:
  IMAGE: alpine

deployments:
  my-simple: ...
  my-other-deployment: ...
  dependent-deployment: ...

dev:
  my-dev: ...
  
commands:
  dev:
    run_watch -p devspace.yaml -- devspace run-pipeline dev

pipelines:
  common:
    run: |-
      # Deploy the deployments in parallel
      create_deployments my-simple my-other-deployment

      # Then deploy the dependent deployment
      create_deployments dependent-deployment
        
      # Starts my-dev configuration if devspace dev and enable terminal as well
      if is_command dev; then
        start_dev my-dev --set terminal.enabled=true
      fi
  deploy:
    run: |-
       # Run the pipeline common
      run_pipelines common
  dev:
    run: |-
      # Run the pipeline common
      run_pipelines common

Imports

You want DRY config and we heard you! With imports you can now merge different devspace.yaml's together and define your variables, deployments, commands and pipelines in a single repository or file and import them into other projects through git, urls or local paths. With the new pipelines you can then define what images to build, what deployments to deploy and what dev configurations to start and stop:

import.yaml

version: v2beta1
name: import1

vars:
  MY_IMPORTED_VAR: test

functions:
  my-function: echo ${MY_IMPORTED_VAR}

pipelines:
  print-var:
    run: |-
      my-function

devspace.yaml

version: v2beta1
name: main

imports:
- path: import.yaml
# Conditionally importing is also possible
- path: import2.yaml
  enabled: $(is_equal ${devspace.namespace} "test")

pipelines:
  dev:
    run: |-
       # will print 'test'
       run_pipelines print-var 

SSH & Proxy Commands

It is now possible to let DevSpace setup an SSH connection as well as proxy certain commands from the local host to the container:

name: devspace-project
dev:
  my-dev:
    imageSelector: nginx
    ssh:
      enabled: true
    proxyCommands:
    - command: git
    - command: devspace
    - command: kubectl

With the configuration above you can run the following (proxyCommands also works with terminal or kubectl exec):

ssh my-dev.devspace-project.devspace
# Run the following commands inside the container that are proxied to the local computer
$/ git 
$/ devspace 
$/ kubectl

!! Breaking Changes !!

DevSpace version 6 introduces some breaking changes to work efficiently with the new Pipelines feature. Almost all older devspace.yaml should still work as config is migrated automatically, however we removed some deprecated and older functionality that we felt is now either obsolete or unused.

Removed Flags:

• --deployments was removed, use pipeline logic instead
• --skip-pipeline in devspace dev was removed, use pipeline logic instead
• --verbose-dependencies and --skip-dependencies was removed and dependencies will be pulled every run
• --interactive was removed from devspace dev, use pipeline logic instead
• --parent-profile was removed, use multiple --profile flags instead
• --restore-vars, --vars-secret and --save-vars was removed. Use vars.MY_VAR.remote: true instead
• --verbose-sync was removed, use --debug instead
• --exit-after-deploy, --terminal-reconnect, --portforwarding and --sync was removed
• --wait, --timeout was removed, use pipeline logic instead
• --container-path and --local-path were removed from devspace sync, please use --path instead

Removed dev.autoReload

This functionality was removed from DevSpace and will be replaced in future by automatically reloading pipelines

DevSpace will no longer ask for undefined variables

If you are using a variable like this, DevSpace will not ask anymore for its value:

deployments:
- name: ...
   helm:
    values:
      key: ${VARIABLE}

rather change it to

vars:
- name: VARIABLE

deployments:
- name: ...
   helm:
    values:
      key: ${VARIABLE}

Dependency names must be unique

DevSpace determines which dependency was deployed now solely based on the name, so multiple dependencies or nested dependencies with the same name will be resolved as the same dependency and deployed only once.

Other Breaking Changes

• Removed devspace use profile instead use profile activation instead
• Removed dependencies[*].skipBuild
• Removed dev.sync[*].onDownload
• Removed deployments[*].helm.driver, deployments[*].helm.deleteArgs, deployments[*].kubectl.deleteArgs and deployments[*].helm.path
• Removed deployments[*].helm.v2
• Dependencies are now purged after deployments are deleted instead of before
• Variables in commands will be resolved by default now
• devspace dev is not taking any arguments anymore

Many other changes!

There are many other improvements and changes that went into this new DevSpace version. We'll release full exhaustive release notes soon.

v6.0.0-beta.6

Config Version v2beta1

With v6 a new config version v2beta1 was introduced, that restructures many parts of the DevSpace config, such as deployments, dev, commands and vars. Older config versions are still supported and will be converted automatically in memory by DevSpace to this new version. To see how the old config got converted, run devspace print, which can be a starting point on how to convert your older DevSpace config.

Pipelines

DevSpace used a declarative approach to define its dev, build, deploy and purge pipeline, however we felt most of it was hardcoded and difficult to change. We introduced hooks to make these pipelines more adjustable, however in many cases this was difficult to understand as the pipeline was still implicit and through hooks scattered around the devspace.yaml.

With DevSpace v6 we introduce a pipelines concept that allows you to override DevSpace default behaviour and create more dynamic and powerful pipelines compared to what DevSpace offers you as a default. These pipelines are written similar to github actions and DevSpace provides custom commands that allow you to build images, deploy deployments as well as stop and start development. This also allows you to define concurrency a lot easier, so from now on you can easily build, deploy or start development in parallel as you desire.

Example: Simple Procedural Pipeline

With pipelines you can decide if to use the declarative approach or define objects on the fly with the --set flag. A simple project that deploys an alpine container and then starts syncing to it can be purely written in the new pipeline form:

version: v2beta1
name: my-project
pipelines:
  # Override the default devspace dev behaviour
  dev:
    run: |-
      # Create a new deployment on the fly with an alpine container
      create_deployments my-simple --set helm.values.containers[0].image=alpine

      # Starts syncing local directory to /app in that container and open a terminal to it
      start_dev my-dev --set imageSelector=alpine \
                       --set sync[0].path=.:/app \
                       --set terminal.enabled=true

Example: Simple Declarative Pipeline

As configurations get more complex, you probably want to reuse config or define it in a separate place, here the declarative approach makes sense that you can reference in your pipeline:

version: v2beta1
name: my-project

vars:
  IMAGE: alpine

deployments:
  my-simple: ...
  my-other-deployment: ...
  dependent-deployment: ...

dev:
  my-dev: ...
  
commands:
  dev:
    run_watch -p devspace.yaml -- devspace run-pipeline dev

pipelines:
  common:
    run: |-
      # Deploy the deployments in parallel
      create_deployments my-simple my-other-deployment

      # Then deploy the dependent deployment
      create_deployments dependent-deployment
        
      # Starts my-dev configuration if devspace dev and enable terminal as well
      if is_command dev; then
        start_dev my-dev --set terminal.enabled=true
      fi
  deploy:
    run: |-
       # Run the pipeline common
      run_pipelines common
  dev:
    run: |-
      # Run the pipeline common
      run_pipelines common

Imports

You want DRY config and we heard you! With imports you can now merge different devspace.yaml's together and define your variables, deployments, commands and pipelines in a single repository or file and import them into other projects through git, urls or local paths. With the new pipelines you can then define what images to build, what deployments to deploy and what dev configurations to start and stop:

import.yaml

version: v2beta1
name: import1

vars:
  MY_IMPORTED_VAR: test

functions:
  my-function: echo ${MY_IMPORTED_VAR}

pipelines:
  print-var:
    run: |-
      my-function

devspace.yaml

version: v2beta1
name: main

imports:
- path: import.yaml
# Conditionally importing is also possible
- path: import2.yaml
  enabled: $(is_equal ${devspace.namespace} "test")

pipelines:
  dev:
    run: |-
       # will print 'test'
       run_pipelines print-var 

SSH & Proxy Commands

It is now possible to let DevSpace setup an SSH connection as well as proxy certain commands from the local host to the container:

name: devspace-project
dev:
  my-dev:
    imageSelector: nginx
    ssh:
      enabled: true
    proxyCommands:
    - command: git
    - command: devspace
    - command: kubectl

With the configuration above you can run the following (proxyCommands also works with terminal or kubectl exec):

ssh my-dev.devspace-project.devspace
# Run the following commands inside the container that are proxied to the local computer
$/ git 
$/ devspace 
$/ kubectl

!! Breaking Changes !!

DevSpace version 6 introduces some breaking changes to work efficiently with the new Pipelines feature. Almost all older devspace.yaml should still work as config is migrated automatically, however we removed some deprecated and older functionality that we felt is now either obsolete or unused.

Removed Flags:

• --deployments was removed, use pipeline logic instead
• --skip-pipeline in devspace dev was removed, use pipeline logic instead
• --verbose-dependencies and --skip-dependencies was removed and dependencies will be pulled every run
• --interactive was removed from devspace dev, use pipeline logic instead
• --parent-profile was removed, use multiple --profile flags instead
• --restore-vars, --vars-secret and --save-vars was removed. Use vars.MY_VAR.remote: true instead
• --verbose-sync was removed, use --debug instead
• --exit-after-deploy, --terminal-reconnect, --portforwarding and --sync was removed
• --wait, --timeout was removed, use pipeline logic instead
• --container-path and --local-path were removed from devspace sync, please use --path instead

Removed dev.autoReload

This functionality was removed from DevSpace and will be replaced in future by automatically reloading pipelines

DevSpace will no longer ask for undefined variables

If you are using a variable like this, DevSpace will not ask anymore for its value:

deployments:
- name: ...
   helm:
    values:
      key: ${VARIABLE}

rather change it to

vars:
- name: VARIABLE

deployments:
- name: ...
   helm:
    values:
      key: ${VARIABLE}

Dependency names must be unique

DevSpace determines which dependency was deployed now solely based on the name, so multiple dependencies or nested dependencies with the same name will be resolved as the same dependency and deployed only once.

Other Breaking Changes

• Removed devspace use profile instead use profile activation instead
• Removed dependencies[*].skipBuild
• Removed dev.sync[*].onDownload
• Removed deployments[*].helm.driver, deployments[*].helm.deleteArgs, deployments[*].kubectl.deleteArgs and deployments[*].helm.path
• Removed deployments[*].helm.v2
• Dependencies are now purged after deployments are deleted instead of before
• Variables in commands will be resolved by default now
• devspace dev is not taking any arguments anymore

Many other changes!

There are many other improvements and changes that went into this new DevSpace version. We'll release full exhaustive release notes soon.

v6.0.0-beta.5

Config Version v2beta1

With v6 a new config version v2beta1 was introduced, that restructures many parts of the DevSpace config, such as deployments, dev, commands and vars. Older config versions are still supported and will be converted automatically in memory by DevSpace to this new version. To see how the old config got converted, run devspace print, which can be a starting point on how to convert your older DevSpace config.

Pipelines

DevSpace used a declarative approach to define its dev, build, deploy and purge pipeline, however we felt most of it was hardcoded and difficult to change. We introduced hooks to make these pipelines more adjustable, however in many cases this was difficult to understand as the pipeline was still implicit and through hooks scattered around the devspace.yaml.

With DevSpace v6 we introduce a pipelines concept that allows you to override DevSpace default behaviour and create more dynamic and powerful pipelines compared to what DevSpace offers you as a default. These pipelines are written similar to github actions and DevSpace provides custom commands that allow you to build images, deploy deployments as well as stop and start development. This also allows you to define concurrency a lot easier, so from now on you can easily build, deploy or start development in parallel as you desire.

Example: Simple Procedural Pipeline

With pipelines you can decide if to use the declarative approach or define objects on the fly with the --set flag. A simple project that deploys an alpine container and then starts syncing to it can be purely written in the new pipeline form:

version: v2beta1
name: my-project
pipelines:
  # Override the default devspace dev behaviour
  dev:
    run: |-
      # Create a new deployment on the fly with an alpine container
      create_deployments my-simple --set helm.values.containers[0].image=alpine

      # Starts syncing local directory to /app in that container and open a terminal to it
      start_dev my-dev --set imageSelector=alpine \
                       --set sync[0].path=.:/app \
                       --set terminal.enabled=true

Example: Simple Declarative Pipeline

As configurations get more complex, you probably want to reuse config or define it in a separate place, here the declarative approach makes sense that you can reference in your pipeline:

version: v2beta1
name: my-project

vars:
  IMAGE: alpine

deployments:
  my-simple: ...
  my-other-deployment: ...
  dependent-deployment: ...

dev:
  my-dev: ...
  
commands:
  dev:
    run_watch -p devspace.yaml -- devspace run-pipeline dev

pipelines:
  common:
    run: |-
      # Deploy the deployments in parallel
      create_deployments my-simple my-other-deployment

      # Then deploy the dependent deployment
      create_deployments dependent-deployment
        
      # Starts my-dev configuration if devspace dev and enable terminal as well
      if is_command dev; then
        start_dev my-dev --set terminal.enabled=true
      fi
  deploy:
    run: |-
       # Run the pipeline common
      run_pipelines common
  dev:
    run: |-
      # Run the pipeline common
      run_pipelines common

Imports

You want DRY config and we heard you! With imports you can now merge different devspace.yaml's together and define your variables, deployments, commands and pipelines in a single repository or file and import them into other projects through git, urls or local paths. With the new pipelines you can then define what images to build, what deployments to deploy and what dev configurations to start and stop:

import.yaml

version: v2beta1
name: import1

vars:
  MY_IMPORTED_VAR: test

functions:
  my-function: echo ${MY_IMPORTED_VAR}

pipelines:
  print-var:
    run: |-
      my-function

devspace.yaml

version: v2beta1
name: main

imports:
- path: import.yaml
# Conditionally importing is also possible
- path: import2.yaml
  enabled: $(is_equal ${devspace.namespace} "test")

pipelines:
  dev:
    run: |-
       # will print 'test'
       run_pipelines print-var 

SSH & Proxy Commands

It is now possible to let DevSpace setup an SSH connection as well as proxy certain commands from the local host to the container:

name: devspace-project
dev:
  my-dev:
    imageSelector: nginx
    ssh:
      enabled: true
    proxyCommands:
    - command: git
    - command: devspace
    - command: kubectl

With the configuration above you can run the following (proxyCommands also works with terminal or kubectl exec):

ssh my-dev.devspace-project.devspace
# Run the following commands inside the container that are proxied to the local computer
$/ git 
$/ devspace 
$/ kubectl

!! Breaking Changes !!

DevSpace version 6 introduces some breaking changes to work efficiently with the new Pipelines feature. Almost all older devspace.yaml should still work as config is migrated automatically, however we removed some deprecated and older functionality that we felt is now either obsolete or unused.

Removed Flags:

• --deployments was removed, use pipeline logic instead
• --skip-pipeline in devspace dev was removed, use pipeline logic instead
• --verbose-dependencies and --skip-dependencies was removed and dependencies will be pulled every run
• --interactive was removed from devspace dev, use pipeline logic instead
• --parent-profile was removed, use multiple --profile flags instead
• --restore-vars, --vars-secret and --save-vars was removed. Use vars.MY_VAR.remote: true instead
• --verbose-sync was removed, use --debug instead
• --exit-after-deploy, --terminal-reconnect, --portforwarding and --sync was removed
• --wait, --timeout was removed, use pipeline logic instead
• --container-path and --local-path were removed from devspace sync, please use --path instead

Removed dev.autoReload

This functionality was removed from DevSpace and will be replaced in future by automatically reloading pipelines

DevSpace will no longer ask for undefined variables

If you are using a variable like this, DevSpace will not ask anymore for its value:

deployments:
- name: ...
   helm:
    values:
      key: ${VARIABLE}

rather change it to

vars:
- name: VARIABLE

deployments:
- name: ...
   helm:
    values:
      key: ${VARIABLE}

Dependency names must be unique

DevSpace determines which dependency was deployed now solely based on the name, so multiple dependencies or nested dependencies with the same name will be resolved as the same dependency and deployed only once.

Other Breaking Changes

• Removed devspace use profile instead use profile activation instead
• Removed dependencies[*].skipBuild
• Removed dev.sync[*].onDownload
• Removed deployments[*].helm.driver, deployments[*].helm.deleteArgs, deployments[*].kubectl.deleteArgs and deployments[*].helm.path
• Removed deployments[*].helm.v2
• Dependencies are now purged after deployments are deleted instead of before
• Variables in commands will be resolved by default now
• devspace dev is not taking any arguments anymore

Many other changes!

There are many other improvements and changes that went into this new DevSpace version. We'll release full exhaustive release notes soon.