You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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: v2beta1name: my-projectpipelines:
# Override the default devspace dev behaviourdev:
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: v2beta1name: my-projectvars:
IMAGE: alpinedeployments:
my-simple: ...my-other-deployment: ...dependent-deployment: ...dev:
my-dev: ...commands:
dev:
run_watch -p devspace.yaml -- devspace run-pipeline devpipelines:
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 fideploy:
run: |- # Run the pipeline common run_pipelines commondev:
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:
With the configuration above you can run the following (proxyCommands also works with terminal or kubectl exec):
ssh my-dev.devspace-project.devspace
# Run the following commands inside the container that are proxied to the local computer
$/ git
$/ devspace
$/ kubectl
!! Breaking Changes !!
DevSpace version 6 introduces some breaking changes to work efficiently with the new Pipelines feature. Almost all older devspace.yaml should still work as config is migrated automatically, however we removed some deprecated and older functionality that we felt is now either obsolete or unused.
Removed Flags:
--deployments was removed, use pipeline logic instead
--skip-pipeline in devspace dev was removed, use pipeline logic instead
--verbose-dependencies and --skip-dependencies was removed and dependencies will be pulled every run
--interactive was removed from devspace dev, use pipeline logic instead
--parent-profile was removed, use multiple --profile flags instead
--restore-vars, --vars-secret and --save-vars was removed. Use vars.MY_VAR.remote: true instead
--verbose-sync was removed, use --debug instead
--exit-after-deploy, --terminal-reconnect, --portforwarding and --sync was removed
--wait, --timeout was removed, use pipeline logic instead
--container-path and --local-path were removed from devspace sync, please use --path instead
Removed dev.autoReload
This functionality was removed from DevSpace and will be replaced in future by automatically reloading pipelines
DevSpace will no longer ask for undefined variables
If you are using a variable like this, DevSpace will not ask anymore for its value:
DevSpace determines which dependency was deployed now solely based on the name, so multiple dependencies or nested dependencies with the same name will be resolved as the same dependency and deployed only once.
Other Breaking Changes
Removed devspace use profile instead use profile activation instead
Removed dependencies[*].skipBuild
Removed dev.sync[*].onDownload
Removed deployments[*].helm.driver, deployments[*].helm.deleteArgs, deployments[*].kubectl.deleteArgs and deployments[*].helm.path
Removed deployments[*].helm.v2
Dependencies are now purged after deployments are deleted instead of before
Variables in commands will be resolved by default now
devspace dev is not taking any arguments anymore
Many other changes!
There are many other improvements and changes that went into this new DevSpace version. We'll release full exhaustive release notes soon.
This discussion was created from the release v6.0.0-beta.0.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
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
andpurge
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: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:
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
devspace.yaml
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:
With the configuration above you can run the following (proxyCommands also works with terminal or
kubectl exec
):!! 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
insteadRemoved
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:
rather change it to
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
devspace use profile
instead use profile activation insteaddependencies[*].skipBuild
dev.sync[*].onDownload
deployments[*].helm.driver
,deployments[*].helm.deleteArgs
,deployments[*].kubectl.deleteArgs
anddeployments[*].helm.path
deployments[*].helm.v2
devspace dev
is not taking any arguments anymoreMany other changes!
There are many other improvements and changes that went into this new DevSpace version. We'll release full exhaustive release notes soon.
This discussion was created from the release v6.0.0-beta.0.
Beta Was this translation helpful? Give feedback.
All reactions