Skip to content

fix(devspace): make dev work against a standalone install - #41

Merged
vitramir merged 5 commits into
mainfrom
fix/devspace-local
Aug 1, 2026
Merged

fix(devspace): make dev work against a standalone install#41
vitramir merged 5 commits into
mainfrom
fix/devspace-local

Conversation

@vitramir

Copy link
Copy Markdown
Contributor

devspace dev could not run at all against the local VM.

  • devspace 6.3.20 rejects a colon in pipeline and command names, so the config failed to parse before doing anything: pipelines.test:e2e has to match the following regex. agents-orchestrator's e2e workflow had been rewriting test:e2etest-e2e in place to get past this; renaming it here removes the need.
  • The deployment was patched by the hardcoded name threads-threads, which only exists when the umbrella chart installs it. A standalone install names it threads. It's now resolved by label, which covers both.

Two things stopped devspace dev from running at all outside the umbrella
chart's layout:

- devspace 6.3.20 rejects a colon in pipeline and command names, so the
  config failed to parse before doing anything. The e2e workflow had been
  rewriting test:e2e to test-e2e in place to get past it.
- The deployment was patched by the hardcoded name threads-threads, which
  only exists when the umbrella chart installs it. It is now resolved by
  label, which covers both layouts.
The selector also pinned app.kubernetes.io/instance to threads, which is
the Helm release name -- true for a standalone install, but the umbrella
chart names it agyn-platform. devspace then waited for a pod that could
not exist and timed out.
The dev container generates from the BSR and compiles before it listens,
which takes minutes on a cold module cache. The chart's liveness probe
killed it at around 40s, so it restarted forever and never served.

Liveness goes. Readiness stays, because without it the pod reports Ready
while nothing is on the port and callers get connection refused, but with
a threshold long enough to cover a cold build.
devspace starts syncing only after the pod reports ready, so a container
that gives up on the sync restarts, and the sync it was waiting for never
lands: the two waited on each other until the backoff won.

The wait is now long enough to lose that race safely, and covers the
whole set generation needs rather than go.mod alone, which could let buf
run against a half synced tree.
devspace does not start syncing until the pod is ready, so a readiness
probe on the service port deadlocks the dev container: no source, so no
listener, so never ready, so no sync. The dev pipeline already waits on
port 50051 itself once the sync is through.
@vitramir
vitramir merged commit 7ed25ce into main Aug 1, 2026
1 check passed
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.

1 participant