devspace

DevSpace - The Fastest Developer Tool for Kubernetes ⚡ Automate your deployment workflow with DevSpace and develop software directly inside Kubernetes.

APACHE-2.0 License

Downloads
5.8K
Stars
4.1K
Committers
101
View Code on GitHub Visit Website View on X
Ecosystems: Kubernetes, Docker, Go

Bot releases are hidden (Show)

devspace - v6.0.0-alpha.10

Published by FabianKramm over 2 years ago

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.

devspace - v6.0.0-alpha.9

Published by FabianKramm over 2 years ago

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.

devspace - v6.0.0-alpha.8

Published by FabianKramm over 2 years ago

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.

devspace - v6.0.0-alpha.7

Published by FabianKramm over 2 years ago

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.

devspace - v6.0.0-alpha.6

Published by FabianKramm over 2 years ago

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.

devspace - v6.0.0-alpha.5

Published by FabianKramm over 2 years ago

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.

devspace - v6.0.0-alpha.4

Published by FabianKramm over 2 years ago

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.

devspace - v6.0.0-alpha.3

Published by FabianKramm over 2 years ago

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.

devspace - v6.0.0-alpha.2

Published by FabianKramm over 2 years ago

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.

devspace - v6.0.0-alpha.1

Published by FabianKramm over 2 years ago

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.

devspace - v6.0.0-alpha.0

Published by FabianKramm over 2 years ago

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.

devspace - v5.18.4

Published by FabianKramm over 2 years ago

Changes

  • Fixed an issue where persistPaths was not correctly working in EKS clusters
  • Improved DevSpace output if the pod DevSpace waits for has a problem
  • New option deployments[*].concurrent that allows you to select deployments that should be deployed concurrently (thanks @erikkrieg @kuuji )
  • On linux or darwin systems, DevSpace will now update out of date file permissions on initial sync
  • Standardized image question for helm, kubectl and kustomizations deployments in devspace init
  • Fixed an issue where imageSelector and containerName couldn't be used together
  • Fixed an issue where DevSpace init can generate configuration that leads to replace pods timeout
devspace - v5.18.4-beta.1

Published by FabianKramm over 2 years ago

Changes

  • Fixed an issue where persistPaths was not correctly working in EKS clusters
  • Improved DevSpace output if the pod DevSpace waits for has a problem
  • New option deployments[*].concurrent that allows you to select deployments that should be deployed concurrently (thanks @erikkrieg @kuuji )
  • On linux or darwin systems, DevSpace will now update out of date file permissions on initial sync
  • Standardized image question for helm, kubectl and kustomizations deployments in devspace init
  • Fixed an issue where DevSpace init can generate configuration that leads to replace pods timeout
devspace - v5.18.4-beta.0

Published by FabianKramm over 2 years ago

Changes

  • New option deployments[*].concurrent that allows you to select deployments that should be deployed concurrently (thanks @erikkrieg @kuuji )
  • On linux or darwin systems, DevSpace will now update out of date file permissions on initial sync
  • Standardized image question for helm, kubectl and kustomizations deployments in devspace init
  • Fixed an issue where DevSpace init can generate configuration that leads to replace pods timeout
devspace - v5.18.3

Published by FabianKramm over 2 years ago

Changes

  • Fixed an issue where DevSpace would change the generated.yaml in plugin or unrelated commands
  • Fixed an issue where volume shared was missing in DevSpace config (#1868)
  • Fixed an issue where DevSpace would print a log message during devspace completion (#1864)
  • Fixed an issue where DevSpace would prompt for a plugin defined variable (#1857)
  • Fixed an issue where DevSpace would include evicted pods in commands (#1880)
  • DevSpace will now run the dev.terminal.command locally if no dev.imageSelector and dev.labelSelector are defined
devspace - v5.18.3-beta.1

Published by FabianKramm over 2 years ago

Changes

  • Fixed an issue where DevSpace would change the generated.yaml in plugin or unrelated commands
  • Fixed an issue where volume shared was missing in DevSpace config (#1868)
  • Fixed an issue where DevSpace would print a log message during devspace completion (#1864)
  • Fixed an issue where DevSpace would prompt for a plugin defined variable (#1857)
  • Fixed an issue where DevSpace would include evicted pods in commands (#1880)
  • DevSpace will now run the dev.terminal.command locally if no dev.imageSelector and dev.labelSelector are defined
devspace - v5.18.3-beta.0

Published by FabianKramm over 2 years ago

Changes

  • Fixed an issue where volume shared was missing in DevSpace config (#1868)
  • Fixed an issue where DevSpace would print a log message during devspace completion (#1864)
  • Fixed an issue where DevSpace would prompt for a plugin defined variable (#1857)
  • DevSpace will now run the dev.terminal.command locally if no dev.imageSelector and dev.labelSelector are defined
devspace - v5.18.2

Published by FabianKramm almost 3 years ago

Changes

  • Fixed an issue where runtime variables would not work correctly in after:build:* hooks
  • Fixed an issue where DevSpace would deploy the same dependency multiple times (#1845)
  • devspace print will now also print the dependency tree
  • Modify patch path conversion to account for possible integer types
  • Removed the devspace help command as it collides with devspace plugin commands (#1841)
  • Fixed an issue where DevSpace would not allow variables in profile paths anymore (#1835)
devspace - v5.18.2-beta.0

Published by FabianKramm almost 3 years ago

Changes

  • Fixed an issue where DevSpace would deploy the same dependency multiple times (#1845)
  • devspace print will now also print the dependency tree
  • Modify patch path conversion to account for possible integer types
  • Removed the devspace help command as it collides with devspace plugin commands (#1841)
  • Fixed an issue where DevSpace would not allow variables in profile paths anymore (#1835)
devspace - v5.18.1

Published by FabianKramm almost 3 years ago

Changes

  • Beta and alpha versions are now allowed for require constraints (#1826)
  • Fixed an issue where DevSpace would panic on devspace sync (#1818)
  • Fixed an issue where DevSpace throws an error of unknown flag with helm v2
  • Fixed an issue where DevSpace was getting Invalid memory address or nil pointer dereference while resolving cyclic dependency (#1818)
  • Fixed an issue where DevSpace would validate config expressions in helm values incorrectly (#1816)
  • Fixed an issue where DevSpace does not run in Alpine when installed via npm (#1185 thanks @tickeegreg)
  • Fixed an issue where DevSpace would not correctly install with npm / yarn
  • Updated k8s dependencies of DevSpace to v1.23.0
Package Rankings
Top 4.02% on Npmjs.org
Top 4.52% on Proxy.golang.org
Badges
Extracted from project README
Join us on Slack! Join us on Slack!
Related Projects
vcluster

vCluster - Create fully functional virtual Kubernetes clusters - Each vcluster runs inside a name...

08 Apr 2021 5,447
terraform-hcloud-kube-hetzner

Optimized and Maintenance-free Kubernetes on Hetzner Cloud in one command!

30 Jul 2021 1,869
microservices-on-cloud-kubernetes

Microservices demo application on cloud-hosted Kubernetes cluster

10 Sep 2020 248
space-cloud

Open source Firebase + Heroku to develop, scale and secure serverless apps on Kubernetes

09 Feb 2019 3,903
blogs

Blogs from @hrittikhere

10 Aug 2022 5
headlamp

A Kubernetes web UI that is fully-featured, user-friendly and extensible

08 Nov 2019 1,620
kube-fledged

A kubernetes operator for creating and managing a cache of container images directly on the clust...

26 Oct 2018 1,246
devpod

Codespaces but open-source, client-only and unopinionated: Works with any IDE and lets you use an...

24 Jan 2023 5,853
kubescape

Kubescape is an open-source Kubernetes security platform for your IDE, CI/CD pipelines, and clust...

12 Aug 2021 10,152
cluster-template

A template for deploying a Talos Kubernetes cluster including Flux for GitOps

14 Apr 2021 1,672
kochhaus-home

Experimental homelab configuration for running things on kubernetes

03 Jun 2021 91
arkade

Open Source Marketplace For Developer Tools

26 Feb 2020 4,211
cnfuzz

Breaking Cloud Native Web APIs in their natural habitat.

14 Mar 2022 35
ml-workspace

🛠 All-in-one web-based IDE specialized for machine learning and data science.

27 May 2019 3,406
OpenShift-Guide

OpenShift Guide. Learn about the Red Hat OpenShift Container Platform, Data Science, Code Ready C...

11 Apr 2021 130