Releases: devspace-sh/devspace
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
indevspace dev
was removed, use pipeline logic instead--verbose-dependencies
and--skip-dependencies
was removed and dependencies will be pulled every run--interactive
was removed fromdevspace dev
, use pipeline logic instead--parent-profile
was removed, use multiple--profile
flags instead--restore-vars
,--vars-secret
and--save-vars
was removed. Usevars.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 fromdevspace 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
anddeployments[*].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
indevspace dev
was removed, use pipeline logic instead--verbose-dependencies
and--skip-dependencies
was removed and dependencies will be pulled every run--interactive
was removed fromdevspace dev
, use pipeline logic instead--parent-profile
was removed, use multiple--profile
flags instead--restore-vars
,--vars-secret
and--save-vars
was removed. Usevars.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 fromdevspace 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
anddeployments[*].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
indevspace dev
was removed, use pipeline logic instead--verbose-dependencies
and--skip-dependencies
was removed and dependencies will be pulled every run--interactive
was removed fromdevspace dev
, use pipeline logic instead--parent-profile
was removed, use multiple--profile
flags instead--restore-vars
,--vars-secret
and--save-vars
was removed. Usevars.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 fromdevspace 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
anddeployments[*].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.4
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
indevspace dev
was removed, use pipeline logic instead--verbose-dependencies
and--skip-dependencies
was removed and dependencies will be pulled every run--interactive
was removed fromdevspace dev
, use pipeline logic instead--parent-profile
was removed, use multiple--profile
flags instead--restore-vars
,--vars-secret
and--save-vars
was removed. Usevars.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 fromdevspace 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
anddeployments[*].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.3
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
indevspace dev
was removed, use pipeline logic instead--verbose-dependencies
and--skip-dependencies
was removed and dependencies will be pulled every run--interactive
was removed fromdevspace dev
, use pipeline logic instead--parent-profile
was removed, use multiple--profile
flags instead--restore-vars
,--vars-secret
and--save-vars
was removed. Usevars.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 fromdevspace 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
anddeployments[*].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.2
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
indevspace dev
was removed, use pipeline logic instead--verbose-dependencies
and--skip-dependencies
was removed and dependencies will be pulled every run--interactive
was removed fromdevspace dev
, use pipeline logic instead--parent-profile
was removed, use multiple--profile
flags instead--restore-vars
,--vars-secret
and--save-vars
was removed. Usevars.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 fromdevspace 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
anddeployments[*].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.1
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
indevspace dev
was removed, use pipeline logic instead--verbose-dependencies
and--skip-dependencies
was removed and dependencies will be pulled every run--interactive
was removed fromdevspace dev
, use pipeline logic instead--parent-profile
was removed, use multiple--profile
flags instead--restore-vars
,--vars-secret
and--save-vars
was removed. Usevars.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 fromdevspace 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
anddeployments[*].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.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
indevspace dev
was removed, use pipeline logic instead--verbose-dependencies
and--skip-dependencies
was removed and dependencies will be pulled every run--interactive
was removed fromdevspace dev
, use pipeline logic instead--parent-profile
was removed, use multiple--profile
flags instead--restore-vars
,--vars-secret
and--save-vars
was removed. Usevars.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 fromdevspace 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
anddeployments[*].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-alpha.19
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
indevspace dev
was removed, use pipeline logic instead--verbose-dependencies
and--skip-dependencies
was removed and dependencies will be pulled every run--interactive
was removed fromdevspace dev
, use pipeline logic instead--parent-profile
was removed, use multiple--profile
flags instead--restore-vars
,--vars-secret
and--save-vars
was removed. Usevars.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 fromdevspace 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
anddeployments[*].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-alpha.18
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
indevspace dev
was removed, use pipeline logic instead--verbose-dependencies
and--skip-dependencies
was removed and dependencies will be pulled every run--interactive
was removed fromdevspace dev
, use pipeline logic instead--parent-profile
was removed, use multiple--profile
flags instead--restore-vars
,--vars-secret
and--save-vars
was removed. Usevars.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 fromdevspace 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
anddeployments[*].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.