devspace.yaml

version: v1beta10

# `images` specifies all images that may need to be built for this project
images:
  app: # This image is called `app` and this name `app` is referenced multiple times in the config below
    image: ghcr.io/loft-sh/devspace-example-spring-boot/spring-app
    dockerfile: ./Dockerfile
    build:
      disabled: true

# `deployments` tells DevSpace how to deploy this project
deployments:
- name: spring-app
  # This deployment uses `helm` but you can also define `kubectl` deployments or kustomizations
  helm:
    # We are deploying the so-called Component Chart: https://devspace.sh/component-chart/docs
    componentChart: true
    # Under `values` we can define the values for this Helm chart used during `helm install/upgrade`
    # You may also use `valuesFiles` to load values from files, e.g. valuesFiles: ["values.yaml"]
    values:
      containers:
      - image: image(app):tag(app) # Use the `app` image (see `images`) and the tag DevSpace generates during image building in your Helm values
      service:
        ports:
        - port: 8080

# `dev` only applies when you run `devspace dev`
dev:
  # `dev.ports` specifies all ports that should be forwarded while `devspace dev` is running
  # Port-forwarding lets you access your application via localhost on your local machine
  ports:
  - imageName: app # Select the Pod that runs our `app` image
    forward:
    - port: 8080

  # `dev.open` tells DevSpace to open certain URLs as soon as they return HTTP status 200
  # Since we configured port-forwarding, we can use a localhost address here to access our application
  open:
  - url: http://localhost:8080

  # `dev.sync` configures a file sync between our Pods in k8s and your local project files
  sync:
  - imageName: app # Select the Pod that runs our `app` image
    excludePaths:
    - .git/
    uploadExcludePaths:
    - Dockerfile
    - target/
    onUpload:
      execRemote:
        onBatch:
          command: sh
          args:
            - -c
            - mvn compile >>/dev/pts/0 || exit 0

  # `dev.terminal` tells DevSpace to open a terminal as a last step during `devspace dev`
  terminal:
    imageName: app
    # With this optional `command` we can tell DevSpace to run a script when opening the terminal
    # This is often useful to display help info for new users or perform initial tasks (e.g. installing dependencies)
    # DevSpace has generated an example ./devspace_start.sh file in your local project - Feel free to customize it!
    command:
    - ./devspace_start.sh

  # Since our Helm charts and manifests deployments are often optimized for production,
  # DevSpace let's you swap out Pods dynamically to get a better dev environment
  replacePods:
  - imageName: app # Select the Pod that runs our `app` image
    # Since our `app` image may be distroless or not have any dev tooling, let's replace it with a dev-optimized image
    # DevSpace provides a sample image here but you can use any image for your specific needs
    replaceImage: loftsh/java-maven:latest
    # Besides replacing the container image, let's also apply some patches to the `spec` of our Pod
    # We are overwriting `command` + `args` for the first container in our selected Pod, so it starts with `sleep 9999999`
    # Using `sleep 9999999` as PID 1 (instead of the regular ENTRYPOINT), allows you to start the application manually
    patches:
    - op: replace
      path: spec.containers[0].command
      value:
      - sleep
    - op: replace
      path: spec.containers[0].args
      value:
      - "9999999"
    - op: remove
      path: spec.containers[0].securityContext

# `profiles` lets you modify the config above for different environments (e.g. dev vs production)
profiles:
  # This profile is called `production` and you can use it for example using: devspace deploy -p production
  # We generally recommend to use the base config without any profiles as optimized for development (e.g. image build+push is disabled)
- name: production
  # This profile applies patches to the config above.
  # In this case, it enables image building for example by removing the `disabled: true` statement for the image `app`
  patches:
  - op: remove
    path: images.app.build.disabled