Command to start port-forwarding independently

[igoooor]

Is your feature request related to a problem? Not a problem

Which solution do you suggest? In the same way that we have devspace sync would it be possible to have something like devspace port-forward and --skip-port-forwarding ?

Which alternative solutions exist? devspace dev -skip-build --skip-push --skip-deploy

Sorry if I overlooked the documentation and if such things already exist but I could not find it

[mahendrabagul]

Hi @igoooor Could you please add details explaining what you are trying to achieve here - an usecase? (a sample devspace yaml would be helpful)

[marklarr-gfm]

Hey there,

We're interested in this functionality as well. Our use case is that we are running devspace deploy inside of our CI process (a GitHub CI runner), and then we want to run some smoke tests against those deployments from the GitHub Runner. In order to run those smoke tests, the GitHub runner needs ports forwarded to the devspace deployments.

We're not using devspace dev in the GitHub runner because it runs indefinitely and requires a ctrl-c to stop it.

Our current work-around is a custom pipeline to deploy a smoke-test-runner pod to our devspace and then kubectl cp the smoke tests there and kubectl exec to run the smoke tests.

[lizardruss]

@marklarr-gfm I think something close to what you desire would be possible with a custom pipeline. I'll share an example to illustrate, but I may have misunderstood the use case:

devspace.yaml

version: v2beta1

deployments:
  app1:
    ... # details omitted
  app2:
    ... # details omitted

pipelines:
  e2e: |-
    # copied from the default pipeline, edit as needed
    run_dependencies --all
    ensure_pull_secrets --all
    build_images --all
    create_deployments --all

    # start port-forwarding, file syncing etc
    start_dev --all

    # run your smoke tests from the GitHub runner
    make tests

    # stop port-forwarding, file syncing etc and exit
    stop_dev --all

dev:
  app1:
    imageSelector: ghcr.io/org/project/app1
    ports:
    - port: "8080:8080"
  app2:
    imageSelector: ghcr.io/org/project/app2
    ports:
    - port: "8181:8080"

You'd run this with:

> devspace run-pipeline e2e

devspace dev would work as it does normally.

This is a pseudo code example, but it's very similar to how we run the e2e tests for our commercial product. It assumes that you wouldn't need to deploy the smoke-test-runner pod and could use the runner to execute tests, but it could be adapted to also use a pod for running smoke tests too.

The main thing is that start_dev and stop_dev can be used to start / stop port forwarding as needed and run any commands you need while port forwarding is active.

[lizardruss]

@igoooor For your use case, I think a custom pipeline + dev configuration would do the trick for only starting port-forwarding. Here's an example:

devspace.yaml

version: v2beta1

deployments:
  app1:
    ... # details omitted
  app2:
    ... # details omitted

pipelines:
  port-forward: |-
    run_dependencies --all
    ensure_pull_secrets --all
    build_images --all
    create_deployments --all

    # Only start the dev sections for port-forwarding
    start_dev app1-pf app2-pf

dev:
  app1-pf:
    imageSelector: ghcr.io/org/project/app1
    ports:
    - port: "8080:8080"
  app2-pf:
    imageSelector: ghcr.io/org/project/app2
    ports:
    - port: "8181:8080"

Similarly you'd run:

devspace run-pipeline port-forward

I think devspace sync could be reproduced with a similar technique, but we kept it for backwards compatibility.

[marklarr-gfm]

@lizardruss thanks for the response. I gave start_dev / stop_dev a try, but I think the issue I am running into is specific to our project's setup. We have a monorepo with several apps, and we're using devspace dependencies to split those apps up into multiple devspace.yaml projects. I've put together a minimal example to show everything I've tried. attempt1, attempt2, attempt3, and attempt4 pipelines all hang indefinitely without a ctrl-c.

10_02_2023.zip

[lizardruss]

@marklarr-gfm Thanks for the example. I see your case a little bit better now. My suggestion would be to only deploy the foo dependency and not attempt to start and stop dev for dependencies from the top level devspace.yaml. Instead, I would add a top level dev configuration that contains the port-forwarding needed for the tests to run.

Here's an example based on the zip files you sent: devspace.yaml

version: v2beta1
name: "10022023"

dependencies:
  foo:
    path: foo/devspace.yaml

pipelines:

  # other attempts omitted

  attempt5: |
    run_dependency_pipelines foo # --pipeline deploy (can define a custom one, just don't use start_dev in it)
    start_dev foo-tests
    echo "hello world"
    stop_dev foo-tests
dev:
  foo-tests:
    labelSelector:
      name: foo
    ports:
      - port: 5000

This does require the top level foo-tests config to have knowledge of the dependencies ports.. but since the test would need that information too, it seems reasonable.

[marklarr-gfm]

@lizardruss We are using dependencies because we have a lot of deployments (10+) and wanted to have some separation of concerns // avoid bloating the root devspace.yaml. I could pull up only the dev sections into the root, but it's unideal because it breaks that separation of concerns (and I'll need to pull up other dev configs as well, like filesync, command, etc)

Are there any potential solutions that would allow us to keep this separation of concerns? Or is a root dev: section the only way forward for us?

[marklarr-gfm]

@lizardruss I think I might try out keeping dev: in the dependencies files (which has ports, filesyncs, commands... etc), but also having a dev: at the root (which has only ports). We'll use the former for development (need the hot-reloading, etc), and we'll use the latter for CI tests.

I'll report back with how that goes.

[lizardruss]

@marklarr-gfm Awesome. Yeah that wasn't clear in my example, but keeping a dev config in the dependencies too is a common pattern. This way you can work on the dependencies independently still. 👍

[marklarr-gfm]

Hey @lizardruss — just reporting back to let you know that it's working now with only the port-forwards copied up to the root devspace.yaml. Thanks for all your help!