🚀 Release v0.30.1 - #5128
Closed
github-actions[bot] wants to merge 44 commits into
Closed
Conversation
The provisioning script pins DOCKER_VERSION=28.5.0 and passes it to get.docker.com via --version. Ubuntu 26.04 (resolute) ships a docker-ce repo with no 28.5.0, so the pin is not found in apt-cache madison and Docker is never installed, aborting setup with 'Failed to initialize Docker Swarm'. Repin to a version present on every architecture Docker ships resolute for. amd64/arm64/armhf start at 29.3.1, but the s390x pool only carries 29.4.0-29.4.2, so 29.3.1 still fails there; 29.4.2 is the newest version common to all shipped arches (ppc64le is not shipped for resolute). The override applies to Ubuntu 26.04 only; all other releases keep 28.5.0, and it runs before the install banner so the reported version stays accurate and both the full-server and build-server paths are covered. Fixes #4327, #4349. Closes #4501.
…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
The preview deployment limit was checked before looking up whether the pull request already had a preview, so once an application reached the limit every `synchronize` event was dropped and existing previews went stale while GitHub still saw a 200. The check now runs inside the branch that creates a preview, uses the schema default of 3 when no limit is configured (instead of 0, which blocked every app without an explicit value) and compares with `>=` so the configured limit is inclusive. Closes #4074
Node.js as PID 1 does not reap children it did not spawn, so the HEALTHCHECK curl fired every 10s accumulates as <defunct>. Install tini and set it as ENTRYPOINT so any orphaned child is reaped while signals still reach Node.
…y for restricted-member project access The application table has 101 columns. The restricted-member branch of project.one (apps/dokploy/server/api/routers/project.ts) queried the applications relation with no columns narrowing, so Drizzle's relational query builder generated a json_build_array call with one argument per column, exceeding Postgres's FUNC_MAX_ARGS (100). Any non-owner/admin member with limited access to a project containing at least one application hit an opaque INTERNAL_SERVER_ERROR and got redirected away from the project/environment page instead of seeing their project. The same branch was also missing the "server" relation that the owner/admin path (findProjectById) already includes, so restricted members saw different (incomplete) data than owners/admins for the same project. Fixes this by extracting the existing serviceColumns column-selection constant to a module-level export in packages/server/src/services/project.ts and applying it (plus the server relation) to all 8 service relations in the restricted-member query path, matching the owner/admin path.
…p-v2 fix: reap HEALTHCHECK zombies by running tini as PID 1
fix: prevent Postgres 100-arg limit crash and restore data parity for restricted-member project access
…holder container ID Fixes #5092 — typing in the database/docker terminal overwrote text instead of continuing on new lines. The xterm.js client never told the backend PTY its actual size (node-pty/ssh2 always defaulted to 80x24 and were never resized), so whenever the rendered terminal width differed from that, the remote shell's cursor math diverged from what the client displayed. - docker-container-terminal.ts / terminal.ts: pass the client's initial cols/rows into node-pty spawn and ssh2 exec/shell, and resize the PTY on a {type:"resize"} control message sent over the same ws channel. - docker-terminal.tsx / settings/web-server/terminal.tsx: send cols/rows on connect and on every term.onResize, and watch the container with a ResizeObserver to refit on dialog/window resize. Also fixes two related terminal/logs bugs surfaced while testing this: - docker-terminal.tsx no longer opens a connection with the "select-a-container" placeholder ID before a real container is selected, and defers terminal creation a frame so React StrictMode's dev-only phantom mount doesn't hit a known xterm.js dispose race (xtermjs/xterm.js#5011, "Cannot read properties of undefined (reading 'dimensions')"). - docker-logs-id.tsx (shared by application/compose/compose-stack logs) had the same placeholder-ID issue, surfacing Docker's raw "No such container: select-a-container" daemon error instead of a proper empty state.
…desync fix: sync terminal size with backend PTY (fixes #5092)
fix(setup): install Docker 29.4.2 on Ubuntu 26.04 to fix failed setup
…container lookup Fixes #5108. The changePassword mutations for postgres/mysql/mariadb/mongo/redis detected the running container via a shell one-liner (docker ps -q --filter status=running | head -n1) executed through execAsync/execAsyncRemote. When that shell command failed for any reason the CONTAINER_ID ended up empty and the mutation incorrectly reported the container as not running even though it was. Replaced it with getServiceContainer(), the existing dockerode-based lookup already used by mount.ts and schedules/utils.ts for the same purpose. Also fixes the postgres ALTER USER command, which never selected a database and defaulted to a database named after the user, causing a false 'database "<user>" does not exist' failure whenever the db name differs from the username.
…ontainer-check fix: false "container is not running" on database password change
The tag dialog's form is nested inside the project dialog's form in the React tree, and React propagates events along the React tree rather than the DOM tree, so submitting the tag form also submitted the project form. The project was created immediately with no tags and the dialog closed before more than one tag could be picked. Stop propagation in the tag form's onSubmit, and select the new tag in the selector so it is included when the project is saved. Fixes #5117
…ition fix: correct switch thumb translate-x for checked state
…reate fix: assign tags created from the project dialog
feat(testing): add upgrade version integration test workflow
fix(github-webhook): apply preview limit only to new previews
fix: don't quote .env values for stack deploys
fix(volume-backups): restart services after backup failure
dosubot
Bot
added
the
size:L
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
Comment on lines
+56
to
+58
| ALL_TAGS=$(curl -fsSL \ | ||
| "https://hub.docker.com/v2/repositories/dokploy/dokploy/tags?page_size=100" | \ | ||
| jq -r '.results[].name' | \ |
Contributor
There was a problem hiding this comment.
The matrix reads only the first 100 Docker Hub tags and does not follow pagination, so eligible historical versions outside that page are silently omitted and their upgrade paths remain untested.
…ner-selection fix: preserve selected stack log container
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
11 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.
This PR promotes changes from
canarytomainfor version v0.30.1.🔍 Changes Include:
✅ Pre-merge Checklist:
Greptile Summary
This release promotes the v0.30.1 canary changes to main.
Confidence Score: 4/5
The PR is not yet safe to merge because the upgrade workflow still omits Docker Hub tags beyond the first page, leaving intended upgrade paths untested.
The outstanding workflow fetches one page of at most 100 tags and builds its entire upgrade matrix from that truncated response, while the repository's production tag-fetching implementation explicitly follows Docker Hub pagination.
Files Needing Attention: .github/workflows/upgrade-integration-test.yml
Reviews (2): Last reviewed commit: "chore: sync hotfix from main into canary..." | Re-trigger Greptile
Context used (3)