Skip to content

fix: don't bake application.yml into the deploy/* images - #2234

Draft
cstamas wants to merge 3 commits into
eclipse-openvsx:mainfrom
cstamas:do-not-bake-in-config
Draft

cstamas wants to merge 3 commits into
eclipse-openvsx:mainfrom
cstamas:do-not-bake-in-config

Conversation

@cstamas

@cstamas cstamas commented Sep 21, 2026

Copy link
Copy Markdown
Member

Summary

The published openvsx-server image (server/Dockerfile) already ships with no Spring config baked in — it's meant to be reused across environments by mounting application.yml into /home/openvsx/server/config at runtime. deploy/kubernetes/ already does this correctly via a ConfigMap volume mount.

deploy/docker/Dockerfile and deploy/openshift/openvsx.Dockerfile didn't: each built a derivative image FROM the base image and COPY'd an environment-specific application.yml into it at build time, then sed- stamped ovsx.registry.version into it. That forced a full image rebuild (re-cloning the repo, rebuilding the web UI) for every config change, defeating "same image, different config" for those two deployment targets.

This brings docker and openshift in line with the kubernetes pattern.

Changes

  • deploy/docker/Dockerfile / deploy/openshift/openvsx.Dockerfile: removed the COPY .../application.yml config/ + sed version-stamping step. These images now only bundle the web UI on top of the base image.
  • deploy/docker/configuration/application.yml / deploy/openshift/application.yml: dropped the ovsx.registry.version: <placeholder> line — the property already defaults to empty (@Value("${ovsx.registry.version:}")), and deploy/kubernetes/configmap.yaml already omits it.
  • deploy/openshift/openvsx-deployment.yml and deploy/openshift/openvsx-deployment-no-es.yml: added an openvsx-server-config ConfigMap (built from application.yml) and mounted it at /home/openvsx/server/config, mirroring deploy/kubernetes/openvsx-server.yaml. The -no-es variant had no config wiring at all and would have broken once the image stopped baking config in, so it needed the same fix.
  • deploy/openshift/README.md / doc/deployment.md: updated to describe the new workflow — a rebuild is only needed for a new OpenVSX version or a different web UI bundle, not for a config change.
  • Added deploy/docker/README.md with build/run instructions showing the config volume mount.

No Java/Spring code changes.

Test plan

  • docker build --check on both modified Dockerfiles — resolves and parses cleanly, no new warnings.
  • Built server/Dockerfile locally and booted it against a live Postgres with no mounted config: fails fast with no active profile / no datasource, confirming the image ships config-free.
  • Same image with application.yml mounted (bind mount) + OAuth env vars: picks up the ovsx profile, runs all Flyway migrations, initializes Hibernate/JobRunr, logs Started RegistryApplication, and serves /actuator/health — confirming the mount-based config path works end-to-end with the same, unmodified image.
  • Validated the OpenShift template YAML (including the embedded application.yml) parses correctly.
  • Not run: ./gradlew test / spotlessCheck (no server source changed, deploy/docs artifacts only).

🤖 Generated with help of Claude Code

…nshift images

The published `openvsx-server` image (`server/Dockerfile`) already ships with
no Spring config baked in — it's meant to be reused across environments by
mounting `application.yml` into `/home/openvsx/server/config` at runtime.
`deploy/kubernetes/` already does this correctly via a ConfigMap volume mount.

`deploy/docker/Dockerfile` and `deploy/openshift/openvsx.Dockerfile` didn't:
each built a derivative image `FROM` the base image and `COPY`'d an
environment-specific `application.yml` into it at build time, then `sed`-
stamped `ovsx.registry.version` into it. That forced a full image rebuild
(re-cloning the repo, rebuilding the web UI) for every config change,
defeating "same image, different config" for those two deployment targets.

This brings `docker` and `openshift` in line with the `kubernetes` pattern.

- `deploy/docker/Dockerfile` / `deploy/openshift/openvsx.Dockerfile`: removed
  the `COPY .../application.yml config/` + `sed` version-stamping step. These
  images now only bundle the web UI on top of the base image.
- `deploy/docker/configuration/application.yml` / `deploy/openshift/application.yml`:
  dropped the `ovsx.registry.version: <placeholder>` line — the property
  already defaults to empty (`@Value("${ovsx.registry.version:}")`), and
  `deploy/kubernetes/configmap.yaml` already omits it.
- `deploy/openshift/openvsx-deployment.yml` and
  `deploy/openshift/openvsx-deployment-no-es.yml`: added an
  `openvsx-server-config` ConfigMap (built from `application.yml`) and
  mounted it at `/home/openvsx/server/config`, mirroring
  `deploy/kubernetes/openvsx-server.yaml`. The `-no-es` variant had no config
  wiring at all and would have broken once the image stopped baking config
  in, so it needed the same fix.
- `deploy/openshift/README.md` / `doc/deployment.md`: updated to describe the
  new workflow — a rebuild is only needed for a new OpenVSX version or a
  different web UI bundle, not for a config change.
- Added `deploy/docker/README.md` with build/run instructions showing the
  config volume mount.

No Java/Spring code changes.

- [x] `docker build --check` on both modified Dockerfiles — resolves and
      parses cleanly, no new warnings.
- [x] Built `server/Dockerfile` locally and booted it against a live
      Postgres with no mounted config: fails fast with no active profile /
      no datasource, confirming the image ships config-free.
- [x] Same image with `application.yml` mounted (bind mount) + OAuth env
      vars: picks up the `ovsx` profile, runs all Flyway migrations,
      initializes Hibernate/JobRunr, logs `Started RegistryApplication`, and
      serves `/actuator/health` — confirming the mount-based config path
      works end-to-end with the *same, unmodified* image.
- [x] Validated the OpenShift template YAML (including the embedded
      `application.yml`) parses correctly.
- [ ] Not run: `./gradlew test` / `spotlessCheck` (no server source changed,
      deploy/docs artifacts only).

🤖 Generated with help of [Claude Code](https://claude.com/claude-code)
@netomi

netomi commented Sep 21, 2026

Copy link
Copy Markdown
Contributor

the openshift deployment is mainly maintained by guys from Redhat according to their needs. Changing that should not be done without consultation with them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants