Releases: devspace-sh/devspace
v6.1.0
Changes
- New option
dev.sync.onUpload.exec.once
to only execute a command a single time in a container's lifecycle - Fixed an issue where
xargs
was sometimes not working correctly for non pipeline functions - Fixed an issue where port-forwarding in devspace could be blocking
- Fixed an issue where DevSpace skipped creating a pull secret when logged in with Azure container registry. (thanks @lizardruss)
- Silent params value being true used to discard the logs, setting it to false will now show the logs on the terminal when --debug is enabled. (thanks @mahendrabagul)
- DevSpace is now aware of sleeping Kubernetes environments and improves the messaging and handling for it
- Bumped component chart to 0.8.5
- Allow
$$()
to escape$()
for config expressions - Fixed an issue where DevSpace would incorrectly omit
\r
in pipeline commands - New
--tty
flag fordevspace enter
to disable tty - New
dev.terminal.disableTTY
option to disable tty - New
wait_pod
function for pipelines that waits for pods / containers to become ready - Variables can now be used in the whole imports section
- DevSpace will not ask a question anymore if stdin is not recognized as a terminal
Other Changes
- fix: bump up golangci-lint version by @pratikjagrut in #2264
- Specify a new section that cannot be patched by @alexissellier in #2260
- Change ConfigPartial ref for open feature by @alexissellier in #2261
- Added config in launch.json to debug devspace cli by @mahendrabagul in #2274
- Fix typo by @FabianKramm in #2276
- Add missing documentation by @alexissellier in #2282
- correct python spelling by @arieldbt in #2287
New Contributors
Full Changelog: v6.0.1...v6.1.0-beta.0
v6.1.0-beta.0
Changes
- New option
dev.sync.onUpload.exec.once
to only execute a command a single time in a container's lifecycle - Fixed an issue where
xargs
was sometimes not working correctly for non pipeline functions - Fixed an issue where port-forwarding in devspace could be blocking
- Fixed an issue where DevSpace skipped creating a pull secret when logged in with Azure container registry. (thanks @lizardruss)
- Silent params value being true used to discard the logs, setting it to false will now show the logs on the terminal when --debug is enabled. (thanks @mahendrabagul)
- DevSpace is now aware of sleeping Kubernetes environments and improves the messaging and handling for it
- Bumped component chart to 0.8.5
- Allow
$$()
to escape$()
for config expressions - Fixed an issue where DevSpace would incorrectly omit
\r
in pipeline commands - New
--tty
flag fordevspace enter
to disable tty - New
dev.terminal.disableTTY
option to disable tty - New
wait_pod
function for pipelines that waits for pods / containers to become ready - Variables can now be used in the whole imports section
- DevSpace will not ask a question anymore if stdin is not recognized as a terminal
Other Changes
- fix: bump up golangci-lint version by @pratikjagrut in #2264
- Specify a new section that cannot be patched by @alexissellier in #2260
- Change ConfigPartial ref for open feature by @alexissellier in #2261
- Added config in launch.json to debug devspace cli by @mahendrabagul in #2274
- Fix typo by @FabianKramm in #2276
- Add missing documentation by @alexissellier in #2282
- correct python spelling by @arieldbt in #2287
New Contributors
Full Changelog: v6.0.1...v6.1.0-beta.0
v6.0.1
What's Changed
- Fixed an issue where DevSpace had problems syncing single files by @FabianKramm in #2257
- Fixed an issue where DevSpace would always re-deploy charts imported using git by @lizardruss in #2244
- Fixed an issue where DevSpace wouldn't resolve environment variable vars correctly by @FabianKramm in #2249
- Fixed an issue where DevSpace incorrectly compared semantic versions. by @CiiDyR in #2250
- Fixed an issue where DevSpace commands were not usable in the DevSpace UI by @FabianKramm in #2251
- Fixed an issue where DevSpace would panic if there would be an empty pipeline, var, command, pullSecret or dev config by @FabianKramm in #2252
- Improved the output if a yaml parsing error occurs @FabianKramm in #2253
- Print error if reserved function name is used in config @FabianKramm in #2253
- Mention that path field can be a URL as well by @alexissellier in #2235
- Fixed an issue where DevSpace was not correctly authenticating to an OCI registry if
chart.username
andchart.password
were provided by @FabianKramm in #2240 - Fixed an issue where DevSpace would spawn many subprocesses if devspace was used as part of a DevSpace variable by @FabianKramm in #2240
New Contributors
- @alexissellier made their first contribution in #2235
Full Changelog: v6.0.0...v6.0.1
v6.0.1-beta.2
What's Changed
- Fixed an issue where DevSpace had problems syncing single files by @FabianKramm in #2257
- Fixed an issue where DevSpace would always re-deploy charts imported using git by @lizardruss in #2244
- Fixed an issue where DevSpace wouldn't resolve environment variable vars correctly by @FabianKramm in #2249
- Fixed an issue where DevSpace incorrectly compared semantic versions. by @CiiDyR in #2250
- Fixed an issue where DevSpace commands were not usable in the DevSpace UI by @FabianKramm in #2251
- Fixed an issue where DevSpace would panic if there would be an empty pipeline, var, command, pullSecret or dev config by @FabianKramm in #2252
- Improved the output if a yaml parsing error occurs @FabianKramm in #2253
- Print error if reserved function name is used in config @FabianKramm in #2253
- Mention that path field can be a URL as well by @alexissellier in #2235
- Fixed an issue where DevSpace was not correctly authenticating to an OCI registry if
chart.username
andchart.password
were provided by @FabianKramm in #2240 - Fixed an issue where DevSpace would spawn many subprocesses if devspace was used as part of a DevSpace variable by @FabianKramm in #2240
New Contributors
- @alexissellier made their first contribution in #2235
Full Changelog: v6.0.0...v6.0.1-beta.2
v6.0.1-beta.1
What's Changed
- Fixed an issue where DevSpace would always re-deploy charts imported using git by @lizardruss in #2244
- Fixed an issue where DevSpace wouldn't resolve environment variable vars correctly by @FabianKramm in #2249
- Fixed an issue where DevSpace incorrectly compared semantic versions. by @CiiDyR in #2250
- Fixed an issue where DevSpace commands were not usable in the DevSpace UI by @FabianKramm in #2251
- Fixed an issue where DevSpace would panic if there would be an empty pipeline, var, command, pullSecret or dev config by @FabianKramm in #2252
- Improved the output if a yaml parsing error occurs @FabianKramm in #2253
- Print error if reserved function name is used in config @FabianKramm in #2253
- Mention that path field can be a URL as well by @alexissellier in #2235
- Fixed an issue where DevSpace was not correctly authenticating to an OCI registry if
chart.username
andchart.password
were provided by @FabianKramm in #2240 - Fixed an issue where DevSpace would spawn many subprocesses if devspace was used as part of a DevSpace variable by @FabianKramm in #2240
New Contributors
- @alexissellier made their first contribution in #2235
Full Changelog: v6.0.0...v6.0.1-beta.1
v6.0.1-beta.0
What's Changed
- Mention that path field can be a URL as well by @alexissellier in #2235
- Fixed an issue where DevSpace was not correctly authenticating to an OCI registry if
chart.username
andchart.password
were provided by @FabianKramm in #2240 - Fixed an issue where DevSpace would spawn many subprocesses if devspace was used as part of a DevSpace variable by @FabianKramm in #2240
New Contributors
- @alexissellier made their first contribution in #2235
Full Changelog: v6.0.0...v6.0.1-beta.0
v6.0.0
Config Version v2beta1
With v6 a new config version v2beta1 was introduced, that restructures many parts of the DevSpace config, such as deployments, dev, commands and vars. Older config versions are still supported and will be converted automatically in memory by DevSpace to this new version. To see how the old config got converted, run devspace print
, which can be a starting point on how to convert your older DevSpace config.
Pipelines
DevSpace used a declarative approach to define its dev
, build
, deploy
and purge
pipeline, however we felt most of it was hardcoded and difficult to change. We introduced hooks to make these pipelines more adjustable, however in many cases this was difficult to understand as the pipeline was still implicit and through hooks scattered around the devspace.yaml.
With DevSpace v6 we introduce a pipelines concept that allows you to override DevSpace default behaviour and create more dynamic and powerful pipelines compared to what DevSpace offers you as a default. These pipelines are written similar to github actions and DevSpace provides custom commands that allow you to build images, deploy deployments as well as stop and start development. This also allows you to define concurrency a lot easier, so from now on you can easily build, deploy or start development in parallel as you desire.
Example: Simple Procedural Pipeline
With pipelines you can decide if to use the declarative approach or define objects on the fly with the --set
flag. A simple project that deploys an alpine container and then starts syncing to it can be purely written in the new pipeline form:
version: v2beta1
name: my-project
pipelines:
# Override the default devspace dev behaviour
dev:
run: |-
# Create a new deployment on the fly with an alpine container
create_deployments my-simple --set helm.values.containers[0].image=alpine
# Starts syncing local directory to /app in that container and open a terminal to it
start_dev my-dev --set imageSelector=alpine \
--set sync[0].path=.:/app \
--set terminal.enabled=true
Example: Simple Declarative Pipeline
As configurations get more complex, you probably want to reuse config or define it in a separate place, here the declarative approach makes sense that you can reference in your pipeline:
version: v2beta1
name: my-project
vars:
IMAGE: alpine
deployments:
my-simple: ...
my-other-deployment: ...
dependent-deployment: ...
dev:
my-dev: ...
commands:
dev:
run_watch -p devspace.yaml -- devspace run-pipeline dev
pipelines:
common:
run: |-
# Deploy the deployments in parallel
create_deployments my-simple my-other-deployment
# Then deploy the dependent deployment
create_deployments dependent-deployment
# Starts my-dev configuration if devspace dev and enable terminal as well
if is_command dev; then
start_dev my-dev --set terminal.enabled=true
fi
deploy:
run: |-
# Run the pipeline common
run_pipelines common
dev:
run: |-
# Run the pipeline common
run_pipelines common
Imports
You want DRY config and we heard you! With imports you can now merge different devspace.yaml's
together and define your variables, deployments, commands and pipelines in a single repository or file and import them into other projects through git, urls or local paths. With the new pipelines you can then define what images to build, what deployments to deploy and what dev configurations to start and stop:
import.yaml
version: v2beta1
name: import1
vars:
MY_IMPORTED_VAR: test
functions:
my-function: echo ${MY_IMPORTED_VAR}
pipelines:
print-var:
run: |-
my-function
devspace.yaml
version: v2beta1
name: main
imports:
- path: import.yaml
# Conditionally importing is also possible
- path: import2.yaml
enabled: $(is_equal ${devspace.namespace} "test")
pipelines:
dev:
run: |-
# will print 'test'
run_pipelines print-var
SSH & Proxy Commands
It is now possible to let DevSpace setup an SSH connection as well as proxy certain commands from the local host to the container:
name: devspace-project
dev:
my-dev:
imageSelector: nginx
ssh:
enabled: true
proxyCommands:
- command: git
- command: devspace
- command: kubectl
With the configuration above you can run the following (proxyCommands also works with terminal or kubectl exec
):
ssh my-dev.devspace-project.devspace
# Run the following commands inside the container that are proxied to the local computer
$/ git
$/ devspace
$/ kubectl
!! Breaking Changes !!
DevSpace version 6 introduces some breaking changes to work efficiently with the new Pipelines feature. Almost all older devspace.yaml
should still work as config is migrated automatically, however we removed some deprecated and older functionality that we felt is now either obsolete or unused.
Removed Flags:
--deployments
was removed, use pipeline logic instead--skip-pipeline
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.10
Config Version v2beta1
With v6 a new config version v2beta1 was introduced, that restructures many parts of the DevSpace config, such as deployments, dev, commands and vars. Older config versions are still supported and will be converted automatically in memory by DevSpace to this new version. To see how the old config got converted, run devspace print
, which can be a starting point on how to convert your older DevSpace config.
Pipelines
DevSpace used a declarative approach to define its dev
, build
, deploy
and purge
pipeline, however we felt most of it was hardcoded and difficult to change. We introduced hooks to make these pipelines more adjustable, however in many cases this was difficult to understand as the pipeline was still implicit and through hooks scattered around the devspace.yaml.
With DevSpace v6 we introduce a pipelines concept that allows you to override DevSpace default behaviour and create more dynamic and powerful pipelines compared to what DevSpace offers you as a default. These pipelines are written similar to github actions and DevSpace provides custom commands that allow you to build images, deploy deployments as well as stop and start development. This also allows you to define concurrency a lot easier, so from now on you can easily build, deploy or start development in parallel as you desire.
Example: Simple Procedural Pipeline
With pipelines you can decide if to use the declarative approach or define objects on the fly with the --set
flag. A simple project that deploys an alpine container and then starts syncing to it can be purely written in the new pipeline form:
version: v2beta1
name: my-project
pipelines:
# Override the default devspace dev behaviour
dev:
run: |-
# Create a new deployment on the fly with an alpine container
create_deployments my-simple --set helm.values.containers[0].image=alpine
# Starts syncing local directory to /app in that container and open a terminal to it
start_dev my-dev --set imageSelector=alpine \
--set sync[0].path=.:/app \
--set terminal.enabled=true
Example: Simple Declarative Pipeline
As configurations get more complex, you probably want to reuse config or define it in a separate place, here the declarative approach makes sense that you can reference in your pipeline:
version: v2beta1
name: my-project
vars:
IMAGE: alpine
deployments:
my-simple: ...
my-other-deployment: ...
dependent-deployment: ...
dev:
my-dev: ...
commands:
dev:
run_watch -p devspace.yaml -- devspace run-pipeline dev
pipelines:
common:
run: |-
# Deploy the deployments in parallel
create_deployments my-simple my-other-deployment
# Then deploy the dependent deployment
create_deployments dependent-deployment
# Starts my-dev configuration if devspace dev and enable terminal as well
if is_command dev; then
start_dev my-dev --set terminal.enabled=true
fi
deploy:
run: |-
# Run the pipeline common
run_pipelines common
dev:
run: |-
# Run the pipeline common
run_pipelines common
Imports
You want DRY config and we heard you! With imports you can now merge different devspace.yaml's
together and define your variables, deployments, commands and pipelines in a single repository or file and import them into other projects through git, urls or local paths. With the new pipelines you can then define what images to build, what deployments to deploy and what dev configurations to start and stop:
import.yaml
version: v2beta1
name: import1
vars:
MY_IMPORTED_VAR: test
functions:
my-function: echo ${MY_IMPORTED_VAR}
pipelines:
print-var:
run: |-
my-function
devspace.yaml
version: v2beta1
name: main
imports:
- path: import.yaml
# Conditionally importing is also possible
- path: import2.yaml
enabled: $(is_equal ${devspace.namespace} "test")
pipelines:
dev:
run: |-
# will print 'test'
run_pipelines print-var
SSH & Proxy Commands
It is now possible to let DevSpace setup an SSH connection as well as proxy certain commands from the local host to the container:
name: devspace-project
dev:
my-dev:
imageSelector: nginx
ssh:
enabled: true
proxyCommands:
- command: git
- command: devspace
- command: kubectl
With the configuration above you can run the following (proxyCommands also works with terminal or kubectl exec
):
ssh my-dev.devspace-project.devspace
# Run the following commands inside the container that are proxied to the local computer
$/ git
$/ devspace
$/ kubectl
!! Breaking Changes !!
DevSpace version 6 introduces some breaking changes to work efficiently with the new Pipelines feature. Almost all older devspace.yaml
should still work as config is migrated automatically, however we removed some deprecated and older functionality that we felt is now either obsolete or unused.
Removed Flags:
--deployments
was removed, use pipeline logic instead--skip-pipeline
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.9
Config Version v2beta1
With v6 a new config version v2beta1 was introduced, that restructures many parts of the DevSpace config, such as deployments, dev, commands and vars. Older config versions are still supported and will be converted automatically in memory by DevSpace to this new version. To see how the old config got converted, run devspace print
, which can be a starting point on how to convert your older DevSpace config.
Pipelines
DevSpace used a declarative approach to define its dev
, build
, deploy
and purge
pipeline, however we felt most of it was hardcoded and difficult to change. We introduced hooks to make these pipelines more adjustable, however in many cases this was difficult to understand as the pipeline was still implicit and through hooks scattered around the devspace.yaml.
With DevSpace v6 we introduce a pipelines concept that allows you to override DevSpace default behaviour and create more dynamic and powerful pipelines compared to what DevSpace offers you as a default. These pipelines are written similar to github actions and DevSpace provides custom commands that allow you to build images, deploy deployments as well as stop and start development. This also allows you to define concurrency a lot easier, so from now on you can easily build, deploy or start development in parallel as you desire.
Example: Simple Procedural Pipeline
With pipelines you can decide if to use the declarative approach or define objects on the fly with the --set
flag. A simple project that deploys an alpine container and then starts syncing to it can be purely written in the new pipeline form:
version: v2beta1
name: my-project
pipelines:
# Override the default devspace dev behaviour
dev:
run: |-
# Create a new deployment on the fly with an alpine container
create_deployments my-simple --set helm.values.containers[0].image=alpine
# Starts syncing local directory to /app in that container and open a terminal to it
start_dev my-dev --set imageSelector=alpine \
--set sync[0].path=.:/app \
--set terminal.enabled=true
Example: Simple Declarative Pipeline
As configurations get more complex, you probably want to reuse config or define it in a separate place, here the declarative approach makes sense that you can reference in your pipeline:
version: v2beta1
name: my-project
vars:
IMAGE: alpine
deployments:
my-simple: ...
my-other-deployment: ...
dependent-deployment: ...
dev:
my-dev: ...
commands:
dev:
run_watch -p devspace.yaml -- devspace run-pipeline dev
pipelines:
common:
run: |-
# Deploy the deployments in parallel
create_deployments my-simple my-other-deployment
# Then deploy the dependent deployment
create_deployments dependent-deployment
# Starts my-dev configuration if devspace dev and enable terminal as well
if is_command dev; then
start_dev my-dev --set terminal.enabled=true
fi
deploy:
run: |-
# Run the pipeline common
run_pipelines common
dev:
run: |-
# Run the pipeline common
run_pipelines common
Imports
You want DRY config and we heard you! With imports you can now merge different devspace.yaml's
together and define your variables, deployments, commands and pipelines in a single repository or file and import them into other projects through git, urls or local paths. With the new pipelines you can then define what images to build, what deployments to deploy and what dev configurations to start and stop:
import.yaml
version: v2beta1
name: import1
vars:
MY_IMPORTED_VAR: test
functions:
my-function: echo ${MY_IMPORTED_VAR}
pipelines:
print-var:
run: |-
my-function
devspace.yaml
version: v2beta1
name: main
imports:
- path: import.yaml
# Conditionally importing is also possible
- path: import2.yaml
enabled: $(is_equal ${devspace.namespace} "test")
pipelines:
dev:
run: |-
# will print 'test'
run_pipelines print-var
SSH & Proxy Commands
It is now possible to let DevSpace setup an SSH connection as well as proxy certain commands from the local host to the container:
name: devspace-project
dev:
my-dev:
imageSelector: nginx
ssh:
enabled: true
proxyCommands:
- command: git
- command: devspace
- command: kubectl
With the configuration above you can run the following (proxyCommands also works with terminal or kubectl exec
):
ssh my-dev.devspace-project.devspace
# Run the following commands inside the container that are proxied to the local computer
$/ git
$/ devspace
$/ kubectl
!! Breaking Changes !!
DevSpace version 6 introduces some breaking changes to work efficiently with the new Pipelines feature. Almost all older devspace.yaml
should still work as config is migrated automatically, however we removed some deprecated and older functionality that we felt is now either obsolete or unused.
Removed Flags:
--deployments
was removed, use pipeline logic instead--skip-pipeline
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.8
Config Version v2beta1
With v6 a new config version v2beta1 was introduced, that restructures many parts of the DevSpace config, such as deployments, dev, commands and vars. Older config versions are still supported and will be converted automatically in memory by DevSpace to this new version. To see how the old config got converted, run devspace print
, which can be a starting point on how to convert your older DevSpace config.
Pipelines
DevSpace used a declarative approach to define its dev
, build
, deploy
and purge
pipeline, however we felt most of it was hardcoded and difficult to change. We introduced hooks to make these pipelines more adjustable, however in many cases this was difficult to understand as the pipeline was still implicit and through hooks scattered around the devspace.yaml.
With DevSpace v6 we introduce a pipelines concept that allows you to override DevSpace default behaviour and create more dynamic and powerful pipelines compared to what DevSpace offers you as a default. These pipelines are written similar to github actions and DevSpace provides custom commands that allow you to build images, deploy deployments as well as stop and start development. This also allows you to define concurrency a lot easier, so from now on you can easily build, deploy or start development in parallel as you desire.
Example: Simple Procedural Pipeline
With pipelines you can decide if to use the declarative approach or define objects on the fly with the --set
flag. A simple project that deploys an alpine container and then starts syncing to it can be purely written in the new pipeline form:
version: v2beta1
name: my-project
pipelines:
# Override the default devspace dev behaviour
dev:
run: |-
# Create a new deployment on the fly with an alpine container
create_deployments my-simple --set helm.values.containers[0].image=alpine
# Starts syncing local directory to /app in that container and open a terminal to it
start_dev my-dev --set imageSelector=alpine \
--set sync[0].path=.:/app \
--set terminal.enabled=true
Example: Simple Declarative Pipeline
As configurations get more complex, you probably want to reuse config or define it in a separate place, here the declarative approach makes sense that you can reference in your pipeline:
version: v2beta1
name: my-project
vars:
IMAGE: alpine
deployments:
my-simple: ...
my-other-deployment: ...
dependent-deployment: ...
dev:
my-dev: ...
commands:
dev:
run_watch -p devspace.yaml -- devspace run-pipeline dev
pipelines:
common:
run: |-
# Deploy the deployments in parallel
create_deployments my-simple my-other-deployment
# Then deploy the dependent deployment
create_deployments dependent-deployment
# Starts my-dev configuration if devspace dev and enable terminal as well
if is_command dev; then
start_dev my-dev --set terminal.enabled=true
fi
deploy:
run: |-
# Run the pipeline common
run_pipelines common
dev:
run: |-
# Run the pipeline common
run_pipelines common
Imports
You want DRY config and we heard you! With imports you can now merge different devspace.yaml's
together and define your variables, deployments, commands and pipelines in a single repository or file and import them into other projects through git, urls or local paths. With the new pipelines you can then define what images to build, what deployments to deploy and what dev configurations to start and stop:
import.yaml
version: v2beta1
name: import1
vars:
MY_IMPORTED_VAR: test
functions:
my-function: echo ${MY_IMPORTED_VAR}
pipelines:
print-var:
run: |-
my-function
devspace.yaml
version: v2beta1
name: main
imports:
- path: import.yaml
# Conditionally importing is also possible
- path: import2.yaml
enabled: $(is_equal ${devspace.namespace} "test")
pipelines:
dev:
run: |-
# will print 'test'
run_pipelines print-var
SSH & Proxy Commands
It is now possible to let DevSpace setup an SSH connection as well as proxy certain commands from the local host to the container:
name: devspace-project
dev:
my-dev:
imageSelector: nginx
ssh:
enabled: true
proxyCommands:
- command: git
- command: devspace
- command: kubectl
With the configuration above you can run the following (proxyCommands also works with terminal or kubectl exec
):
ssh my-dev.devspace-project.devspace
# Run the following commands inside the container that are proxied to the local computer
$/ git
$/ devspace
$/ kubectl
!! Breaking Changes !!
DevSpace version 6 introduces some breaking changes to work efficiently with the new Pipelines feature. Almost all older devspace.yaml
should still work as config is migrated automatically, however we removed some deprecated and older functionality that we felt is now either obsolete or unused.
Removed Flags:
--deployments
was removed, use pipeline logic instead--skip-pipeline
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.