feat(testing): add upgrade version integration test workflow#4702
Open
Xeoneid wants to merge 7 commits into
Open
feat(testing): add upgrade version integration test workflow#4702Xeoneid wants to merge 7 commits into
Xeoneid wants to merge 7 commits into
Conversation
…ia DOKPLOY_VERSION Previous run failed with 'This script must be run as root'. install.sh also respects DOKPLOY_VERSION and ADVERTISE_ADDR env vars, so we can install version A directly instead of installing latest and downgrading (which would risk B's migrations running on A's expected schema).
…nse formats
In Dokploy <= ~v0.24, project.create returns a flat object with just
projectId at the top level; no environment concept exists yet, so
resources (postgres, mongo, apps) are created with projectId.
In Dokploy >= ~v0.25, project.create returns nested {project, environment}
objects and resources require environmentId.
Previous workflow always used .project.projectId and .environment.environmentId,
both of which evaluated to null on old versions, causing curl to exit with
code 22 (HTTP error) on every subsequent resource-create call.
Fix: extract PROJECT_ID with a // fallback, check ENV_ID nullness, and
build a SCOPE fragment (either 'environmentId' or 'projectId') used in
all resource-creation tRPC calls.
…reate v0.20.x used a completely different postgres/mongo/app API schema — projectId fallback returned boolean false, not the expected resource object. Since the goal is testing v0.29.4+, drop the old-API compatibility shim and fail fast with a clear message if environmentId is missing. Also: default floor_version changed from v0.20.0 to v0.29.4 to reduce the number of matrix jobs and focus on the stable modern API surface.
The create step was calling postgres.start / mongo.start immediately after create. In Dokploy, .start only scales an already-deployed Swarm service; on a freshly created resource the service doesn't exist yet, so the server ran 'docker service scale ci-pg-db-xxx=1' against a missing service and returned a 500 (curl -sf → exit 22 → step failure). .deploy is the mutation that actually builds and creates the Swarm service. Applications already used .deploy correctly; this aligns the databases.
- Replace "every version → latest" with consecutive pairs (v[i] → v[i+1]) - Remove curated v0.25→v0.26 pair logic - Remove extra_pairs workflow_dispatch input
- Replace second form field (extra_pairs) with target_version
- target_version sets version B ("to"); empty = highest available tag
- Pair every tag in [floor_version, target_version) with target_version
Xeoneid
changed the title
dosubot
Bot
added
size:XS
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Recent releases have surfaced upgrade regressions — services broken, logs lost, containers failing to start (see #4049, #4245, #4367). This PR adds a manually-triggered GitHub Actions workflow that validates Dokploy's upgrade path across multiple version pairs, catching these regressions before they reach users.
What the workflow does
[floor_version, target_version)is paired withtarget_version(defaults to the highest available tag). Each pair becomes an independent matrix job.install.shusing theDOKPLOY_VERSIONenv var — no "install latest then downgrade" step, which would risk running version B's migrations against version A's schema.1/1and all resource statusesdone.docker service update --image.Design decisions
v[i] → v[i+1]) instead of "every version → latest" — mirrors real-world sequential upgrades and keeps the matrix bounded.fail-fast: false— all pairs run independently so failures are isolated to specific version transitions.workflow_dispatchonly — manual trigger to avoid burning Actions minutes on every push.CiTest1234!,CiPg1pass,CiMg1pass) are intentional throwaway values on ephemeral CI runners only.Test plan
Actions → Upgrade Integration Test → Run workflowfloor_version/target_version1/1, all statusesdoneRelated
Upgrade regressions that motivated this workflow: