Repository navigation
Tags: sourcegraph/deploy-sourcegraph-docker
Tags
fix: update v7.5.4453 Docker Compose image manifests (#1407) ## Summary - update both release-managed Docker Compose manifests to public Sourcegraph 7.5.4453 images - pin each image to its promoted digest - repair the `release-v7.5.4453` branch before moving tag `v7.5.4453` to the corrected branch head ## Impact The current `v7.5.4453` tag contains stale Docker Compose image references, including Sourcegraph 6.1 and PostgreSQL 6.0 images. Users checking out the 7.5.4453 tag therefore do not receive the images produced for the 7.5.4453 search release. ## What happened The Temporal `UpdateDockerImages` activity completed successfully and reported both expected files as updated. It created commit `d20cc5d6f1da12a6872fa968b9f927c18cc904c6` (`Update compose images to v7.5.4453`). That commit contains the expected internal image changes, but it is no longer reachable from the release branch. One second later, the workflow created the empty Buildkite configuration commit `7e757fd508c04ea857580b1438c7108602eaca2d`. Both commits have the same parent, `31be4b977b9b9c28f9ccc4a4a2a188a972ab0f54`, rather than the configuration commit having the image-update commit as its parent: ``` 31be4b ├── d20cc5d Update compose images to v7.5.4453 (orphaned) └── 7e757fd release: v7.5.4453 (branch head) ``` Our hypothesis is that the GitHub ref read performed by the configuration-commit activity briefly returned the old branch head after the image activity had updated it. The configuration commit was consequently created from the stale parent. The workflow then force-updated the branch ref, replacing the image commit instead of advancing from it. This matches the implementation: the generic commit input supports an explicit `ParentCommitSHA` to avoid GitHub eventual-consistency races, but the empty configuration-commit path fetches the branch head again and does not chain directly from the image activity result. The ref update is also forced, allowing a stale, non-fast-forward commit to silently replace the previous branch head. This would explain why prior releases worked: the race depends on whether the updated GitHub ref is visible before the immediately following activity reads it. The k8s workflow performs multiple commits and has more time between its first update and configuration commit. ## Follow-up After this PR merges, move tag `v7.5.4453` to the merged `release-v7.5.4453` branch head so checkouts of the tag receive these corrected manifests. The workflow should separately be hardened by explicitly chaining the configuration commit from the image-update commit and avoiding forced ref updates for normal sequential commits. ## Test plan - verified the PR changes only the two manifests processed by `UpdateDockerImages` - verified all Sourcegraph image references use tag `7.5.4453` and pinned public digests - verified the promoted digests against the k8s release manifests; verified the caddy digest directly against Docker Hub - ran `git diff --check`
PreviousNext