fix(preview): re-clone source on rebuild so PR pushes propagate

[budivoogt]

Problem

rebuildPreviewApplication skips the clone step that deployPreviewApplication runs on first deploy. As a result, every PR synchronize webhook (i.e., every push to an existing preview branch after the first) only re-runs docker build against the original snapshot taken at PR open.

BuildKit content-hashes the unchanged source, cache-hits every layer including COPY . ., and the deploy finishes in seconds while still serving the original commit. The GitHub Deployments API gets posted `success`, but the running container is never replaced.

Reproduction

Verified empirically on a self-hosted v0.28.8 install:

1. Open a PR at SHA A — real ~4 min build, image hash A1, container running new code. ✅
2. Push SHA B, then C, then D to the same PR. Three synchronize events, three Dokploy "deploys" each finishing in 9–10 s, GitHub Deployments reports each as `success`. The Docker image and running container keep hash `A1`. Working tree on disk and BuildKit cache both stuck at SHA `A`.
3. Manually run `git fetch + git reset --hard origin/` on `/etc/dokploy/applications//code/`, then trigger a redeploy. The next build cache-misses `COPY . .`, takes ~4 min, and produces a fresh image with the new commit's code.

The only thing missing for the rebuild path was the fetch.

Fix

Mirror deployPreviewApplication's pre-build clone in rebuildPreviewApplication. cloneGithubRepository already does `rm -rf code && git clone --depth 1 --branch ` with a fresh installation token issued via the GitHub App — so each rebuild gets the latest tip of the preview branch.

The diff is symmetric with the existing block at line ~427 inside deployPreviewApplication.

Scope

GitHub source type only, matching the existing scope of deployPreviewApplication's clone. GitLab / Gitea / Bitbucket preview rebuilds remain on the previous behavior; extending parity to those providers belongs in a follow-up. Happy to do that in this PR if maintainers prefer — just let me know.

Test plan

• Open a PR against an app with GitHub source + preview deployments enabled. Confirm build runs to completion.
• Push a follow-up commit to that PR. Confirm the next deploy:
  • Shows in build log: a fresh `git clone` step (not an immediately-cached `COPY . .` layer)
  • Takes a real build duration (4–5 min for our codebase, will vary)
  • Produces a new docker image hash
  • Container picks up the new commit's code (verified in browser, e.g. a string change in the page)

Related

Verified on v0.28.8; same bug is in v0.29.2 (latest as of this PR — same line, same comment). No prior issue or PR found in tracker for this specific behavior. Closest existing reports are about preview deployment lifecycle (#3248 Destroy & Re-Deploy button, #4203 orphan Swarm services) but not the stale-source-on-rebuild path.

Greptile Summary

This PR fixes a real bug where rebuildPreviewApplication skipped the repository clone step, causing every PR push after the first to rebuild against the original source snapshot. The fix mirrors deployPreviewApplication's clone block exactly, scoped to sourceType === "github" as acknowledged in the description.

Confidence Score: 5/5

This PR is safe to merge — it's a targeted, well-scoped fix with no regressions.

The change is a minimal, symmetric addition that directly mirrors the already-working pattern in deployPreviewApplication. Error handling flows through the existing catch block, the GitHub App token is freshly issued on each call, and non-GitHub source types are explicitly left unchanged (as stated in the description). No new execution paths, no security concerns.

No files require special attention.

_{Reviews (1): Last reviewed commit: "fix(preview): re-clone source on rebuild..." | Re-trigger Greptile}