devspace

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

APACHE-2.0 License

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

Bot releases are hidden (Show)

devspace - v6.2.1

Published by lizardruss almost 2 years ago

What's Changed

New Contributors

Full Changelog: https://github.com/loft-sh/devspace/compare/v6.2.0...v6.2.1

devspace - v6.2.0

Published by lizardruss almost 2 years ago

Local Registry

DevSpace now makes it even easier to start developing on Kubernetes. In many cases, it can be difficult to get started when you don't have an established way of pushing images between your local environment and a remote cluster. Setting up a registry when you're only evaluating Kubernetes and DevSpace is sometimes too much to ask.

DevSpace will detect whether you are using a local or remote cluster. When using a remote cluster DevSpace will check if you have push permissions to the image's registry. When you do not have push permissions, DevSpace will deploy an image registry to your cluster with a NodePort service, start port forwarding between your localhost and the registry pod, and update your image URLs to use the new localhost registry URL. The remote cluster will now resolve images from the deployed registry.

For cases when you are using a local Kubernetes cluster, or have push permissions to a remote registry, DevSpace will behave exactly as before. No additional configuration is needed in devspace.yaml, but if you wish to enabled persistence for the local registry, or use a custom registry image, configuration options are available.

What's Changed

Other Changes

New Contributors

Full Changelog: https://github.com/loft-sh/devspace/compare/v6.1.1...v6.2.0

devspace - v6.2.0-beta.0

Published by lizardruss almost 2 years ago

Local Registry

DevSpace now makes it even easier to start developing on Kubernetes. In many cases, it can be difficult to get started when you don't have an established way of pushing images between your local environment and a remote cluster. Setting up a registry when you're only evaluating Kubernetes and DevSpace is sometimes too much to ask.

DevSpace will detect whether you are using a local or remote cluster. When using a remote cluster DevSpace will check if you have push permissions to the image's registry. When you do not have push permissions, DevSpace will deploy an image registry to your cluster with a NodePort service, start port forwarding between your localhost and the registry pod, and update your image URLs to use the new localhost registry URL. The remote cluster will now resolve images from the deployed registry.

For cases when you are using a local Kubernetes cluster, or have push permissions to a remote registry, DevSpace will behave exactly as before. No additional configuration is needed in devspace.yaml, but if you wish to enabled persistence for the local registry, or use a custom registry image, configuration options are available.

What's Changed

Other Changes

New Contributors

Full Changelog: https://github.com/loft-sh/devspace/compare/v6.1.1...v6.2.0-beta.0

devspace - v6.2.0-alpha.0

Published by lizardruss almost 2 years ago

Local Registry

DevSpace now makes it even easier to start developing on Kubernetes. In many cases, it can be difficult to get started when you don't have an established way of pushing images between your local environment and a remote cluster. Setting up a registry when you're only evaluating Kubernetes and DevSpace is sometimes too much to ask.

DevSpace will detect whether you are using a local or remote cluster. When using a remote cluster DevSpace will check if you have push permissions to the image's registry. When you do not have push permissions, DevSpace will deploy an image registry to your cluster with a NodePort service, start port forwarding between your localhost and the registry pod, and update your image URLs to use the new localhost registry URL. The remote cluster will now resolve images from the deployed registry.

For cases when you are using a local Kubernetes cluster, or have push permissions to a remote registry, DevSpace will behave exactly as before. No additional configuration is needed in devspace.yaml, but if you wish to enabled persistence for the local registry, or use a custom registry image, configuration options are available.

What's Changed

Other Changes

New Contributors

Full Changelog: https://github.com/loft-sh/devspace/compare/v6.1.2-alpha.0...v6.2.0-alpha.0

devspace - v6.1.2-alpha.0

Published by FabianKramm about 2 years ago

What's Changed

New Contributors

Full Changelog: https://github.com/loft-sh/devspace/compare/v6.1.1...v6.1.2-alpha.0

devspace - v5.18.6-beta.0

Published by FabianKramm about 2 years ago

What's Changed

Full Changelog: https://github.com/loft-sh/devspace/compare/v5.18.5...v5.18.6-beta.0

devspace - v6.1.1

Published by FabianKramm about 2 years ago

What's Changed

Full Changelog: https://github.com/loft-sh/devspace/compare/v6.1.0...v6.1.1

devspace - v6.1.1-beta.0

Published by FabianKramm about 2 years ago

What's Changed

Full Changelog: https://github.com/loft-sh/devspace/compare/v6.1.0...v6.1.1-beta.0

devspace - v6.1.0

Published by FabianKramm about 2 years ago

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 for devspace 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

New Contributors

Full Changelog: https://github.com/loft-sh/devspace/compare/v6.0.1...v6.1.0-beta.0

devspace - v6.1.0-beta.0

Published by FabianKramm about 2 years ago

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 for devspace 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

New Contributors

Full Changelog: https://github.com/loft-sh/devspace/compare/v6.0.1...v6.1.0-beta.0

devspace - v6.0.1

Published by FabianKramm about 2 years ago

What's Changed

New Contributors

Full Changelog: https://github.com/loft-sh/devspace/compare/v6.0.0...v6.0.1

devspace - v6.0.1-beta.2

Published by FabianKramm about 2 years ago

What's Changed

New Contributors

Full Changelog: https://github.com/loft-sh/devspace/compare/v6.0.0...v6.0.1-beta.2

devspace - v6.0.1-beta.1

Published by FabianKramm about 2 years ago

What's Changed

New Contributors

Full Changelog: https://github.com/loft-sh/devspace/compare/v6.0.0...v6.0.1-beta.1

devspace - v6.0.1-beta.0

Published by FabianKramm about 2 years ago

What's Changed

New Contributors

Full Changelog: https://github.com/loft-sh/devspace/compare/v6.0.0...v6.0.1-beta.0

devspace - v6.0.0

Published by FabianKramm about 2 years ago

Config Version v2beta1

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

Pipelines

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

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

Example: Simple Procedural Pipeline

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

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

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

Example: Simple Declarative Pipeline

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

version: v2beta1
name: my-project

vars:
  IMAGE: alpine

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

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

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

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

Imports

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

import.yaml

version: v2beta1
name: import1

vars:
  MY_IMPORTED_VAR: test

functions:
  my-function: echo ${MY_IMPORTED_VAR}

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

devspace.yaml

version: v2beta1
name: main

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

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

SSH & Proxy Commands

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

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

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

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

!! Breaking Changes !!

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

Removed Flags:

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

Removed dev.autoReload

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

DevSpace will no longer ask for undefined variables

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

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

rather change it to

vars:
- name: VARIABLE

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

Dependency names must be unique

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

Other Breaking Changes

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

Many other changes!

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

devspace - v6.0.0-beta.10

Published by FabianKramm about 2 years ago

Config Version v2beta1

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

Pipelines

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

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

Example: Simple Procedural Pipeline

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

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

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

Example: Simple Declarative Pipeline

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

version: v2beta1
name: my-project

vars:
  IMAGE: alpine

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

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

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

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

Imports

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

import.yaml

version: v2beta1
name: import1

vars:
  MY_IMPORTED_VAR: test

functions:
  my-function: echo ${MY_IMPORTED_VAR}

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

devspace.yaml

version: v2beta1
name: main

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

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

SSH & Proxy Commands

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

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

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

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

!! Breaking Changes !!

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

Removed Flags:

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

Removed dev.autoReload

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

DevSpace will no longer ask for undefined variables

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

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

rather change it to

vars:
- name: VARIABLE

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

Dependency names must be unique

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

Other Breaking Changes

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

Many other changes!

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

devspace - v6.0.0-beta.9

Published by FabianKramm about 2 years ago

Config Version v2beta1

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

Pipelines

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

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

Example: Simple Procedural Pipeline

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

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

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

Example: Simple Declarative Pipeline

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

version: v2beta1
name: my-project

vars:
  IMAGE: alpine

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

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

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

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

Imports

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

import.yaml

version: v2beta1
name: import1

vars:
  MY_IMPORTED_VAR: test

functions:
  my-function: echo ${MY_IMPORTED_VAR}

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

devspace.yaml

version: v2beta1
name: main

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

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

SSH & Proxy Commands

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

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

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

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

!! Breaking Changes !!

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

Removed Flags:

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

Removed dev.autoReload

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

DevSpace will no longer ask for undefined variables

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

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

rather change it to

vars:
- name: VARIABLE

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

Dependency names must be unique

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

Other Breaking Changes

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

Many other changes!

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

devspace - v6.0.0-beta.8

Published by FabianKramm about 2 years ago

Config Version v2beta1

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

Pipelines

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

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

Example: Simple Procedural Pipeline

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

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

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

Example: Simple Declarative Pipeline

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

version: v2beta1
name: my-project

vars:
  IMAGE: alpine

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

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

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

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

Imports

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

import.yaml

version: v2beta1
name: import1

vars:
  MY_IMPORTED_VAR: test

functions:
  my-function: echo ${MY_IMPORTED_VAR}

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

devspace.yaml

version: v2beta1
name: main

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

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

SSH & Proxy Commands

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

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

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

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

!! Breaking Changes !!

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

Removed Flags:

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

Removed dev.autoReload

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

DevSpace will no longer ask for undefined variables

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

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

rather change it to

vars:
- name: VARIABLE

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

Dependency names must be unique

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

Other Breaking Changes

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

Many other changes!

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

devspace - v6.0.0-beta.7

Published by FabianKramm about 2 years ago

Config Version v2beta1

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

Pipelines

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

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

Example: Simple Procedural Pipeline

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

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

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

Example: Simple Declarative Pipeline

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

version: v2beta1
name: my-project

vars:
  IMAGE: alpine

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

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

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

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

Imports

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

import.yaml

version: v2beta1
name: import1

vars:
  MY_IMPORTED_VAR: test

functions:
  my-function: echo ${MY_IMPORTED_VAR}

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

devspace.yaml

version: v2beta1
name: main

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

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

SSH & Proxy Commands

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

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

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

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

!! Breaking Changes !!

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

Removed Flags:

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

Removed dev.autoReload

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

DevSpace will no longer ask for undefined variables

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

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

rather change it to

vars:
- name: VARIABLE

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

Dependency names must be unique

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

Other Breaking Changes

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

Many other changes!

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

devspace - v6.0.0-beta.6

Published by FabianKramm over 2 years ago

Config Version v2beta1

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

Pipelines

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

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

Example: Simple Procedural Pipeline

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

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

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

Example: Simple Declarative Pipeline

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

version: v2beta1
name: my-project

vars:
  IMAGE: alpine

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

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

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

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

Imports

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

import.yaml

version: v2beta1
name: import1

vars:
  MY_IMPORTED_VAR: test

functions:
  my-function: echo ${MY_IMPORTED_VAR}

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

devspace.yaml

version: v2beta1
name: main

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

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

SSH & Proxy Commands

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

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

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

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

!! Breaking Changes !!

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

Removed Flags:

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

Removed dev.autoReload

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

DevSpace will no longer ask for undefined variables

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

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

rather change it to

vars:
- name: VARIABLE

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

Dependency names must be unique

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

Other Breaking Changes

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

Many other changes!

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

Package Rankings
Top 4.02% on Npmjs.org
Top 4.52% on Proxy.golang.org
Badges
Extracted from project README
Join us on Slack! Join us on Slack!
Related Projects
kubescape

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

12 Aug 2021 10,152
kube-fledged

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

26 Oct 2018 1,246
arkade

Open Source Marketplace For Developer Tools

26 Feb 2020 4,211
cnfuzz

Breaking Cloud Native Web APIs in their natural habitat.

14 Mar 2022 35
cluster-template

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

14 Apr 2021 1,672
space-cloud

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

09 Feb 2019 3,903
ml-workspace

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

27 May 2019 3,406
blogs

Blogs from @hrittikhere

10 Aug 2022 5
microservices-on-cloud-kubernetes

Microservices demo application on cloud-hosted Kubernetes cluster

10 Sep 2020 248
headlamp

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

08 Nov 2019 1,620
devpod

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

24 Jan 2023 5,853
OpenShift-Guide

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

11 Apr 2021 130
vcluster

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

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

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

30 Jul 2021 1,869
kochhaus-home

Experimental homelab configuration for running things on kubernetes

03 Jun 2021 91