Publish as countly-drill-migrator and build main without cutting a release - #9
Open
Hakandede wants to merge 1 commit into
Open
Publish as countly-drill-migrator and build main without cutting a release#9Hakandede wants to merge 1 commit into
Hakandede wants to merge 1 commit into
Conversation
Two problems with the previous workflow. The image name was shared with the previous, Redis-based migration service, whose tags run up to 1.9.x on Docker Hub. Publishing this service there would mix two different services in one tag series, make latest depend on release order, and let a chart default resolve to an old build. It now publishes as countly-drill-migrator, with its own tag series. The only trigger was a published release, so the sole way to obtain any image was to cut a public one. Pushes to main and manual runs now publish a main-<sha> tag as well, which is enough to test with; releases keep producing clean semver tags. Doc-only and k8s-only pushes are skipped.
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
1 participant
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.
Two problems
1. The image name is shared with the previous service. Docker Hub
countly/countly-migrationholds the Redis-based migration service, tags1.0.0through1.9.3(April 2026), and this repo's releases run to 1.9.3 to match. Publishing the ledger service under that name would put two different services in one tag series, makelatestdepend on release order, and — concretely — the Helm chart's default (appVersion: 1.0.0) resolves tocountly/countly-migration:1.0.0, which is an old Redis-era build. A deploy from chart defaults would quietly run the wrong service rather than failing.2. The only trigger was a published release. So the only way to obtain any image at all was to cut a public release. The ledger merge to
mainproduced nothing, and testing so far has depended on hand-built images.Changes
IMAGE_NAME→${{ secrets.DOCKERHUB_USERNAME }}/countly-drill-migrator. Own name, own tag series, starting clean at whatever release you publish first. The old image stays untouched for anyone still on the old method.push: branches: [main]andworkflow_dispatch, withtype=sha,prefix=main-so those runs publishmain-<sha>. Releases keep producing{{version}}/{{major}}.{{minor}}/{{major}}exactly as before.paths-ignorefor**.md,docs/**andk8s/**, so documentation pushes don't rebuild.No change to the Dockerfile, the build context, the platform (
linux/amd64) or the GHA cache.After merging
A
main-<sha>image appears on the next push tomain(or immediately via Run workflow), which is what the Helm chart can be pointed at for end-to-end verification — includingLEDGER_START_PAUSED, which no published image contains yet.The matching chart-side change (
image.repository→countly-drill-migrator) goes on Countly/helm#92.Note the Docker Hub account behind
DOCKERHUB_USERNAMEneeds to allow creating a new repository, or the first push fails on a missing repo.