Conversation
Three things in RELEASE.md did not match how releasing actually works, all found while cutting v0.3.0. Step 8 said to open an issue in devops-cloud-infra. Deployment moved to Kargo, the image tag is written by a promotion, and there is no version pinned in that repo, so neither an issue nor a PR moves anything. It now describes the promotion, including that the Warehouse only matches the date stamped tag and that production stages source per chain from the matching westend stage. Step 7 said creating the GitHub release publishes the Docker image. Nothing triggers on release creation. The v* tag push in step 5 does it, which is why the image existed seven minutes before the v0.3.0 release was created. Step 6 presented the crates.io commands as one sequence. The server dry run cannot resolve the config crate until config is published, so it fails if run ahead of time.
This branch has not been deployed
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.
Description
Three things in RELEASE.md did not match how releasing actually works. All of them turned up while cutting
v0.3.0.Step 8 was the wrong task entirely. It said to open an issue in
devops-cloud-infra, which predates the Kargo setup. The image tag is written by a Kargo promotion, so nothing in that repo pins a version and neither an issue nor a PR moves the deployment. Thevalues-*.yamlfiles carry ingress, env and service config only. Rewritten to describe the promotion: the Kargo URL, that the Warehouse only matches theYYYYMMDD-HHMMSS-<sha8>tag so the semver tag is invisible to it, and that production stages source per chain from the matching westend stage, so promoting onlywestend-hubleaves the relay instances behind.Step 7 credited the wrong trigger. It said creating the GitHub release publishes the Docker image. No workflow triggers on release creation;
deploy.ymlfires on thev*tag push from step 5. Forv0.3.0the image was on Docker Hub at 16:27 and the release was created at 16:34, so the release cannot have produced it. Now says what the tag push publishes, all three tags and which one Kargo consumes, and that the release is notes only.Step 6 read as one clean sequence.
cargo publish -p polkadot-rest-api --dry-runcannot resolvepolkadot-rest-api-configuntil config is on the index, so it fails if you run it ahead of publishing config. Added a note so that failure is recognisable rather than alarming.Also pointed the step 9 check at the six instances instead of a vague "all public instances up to date", using the same loop.
Verified
The verification loop in step 8 is the one I actually ran after promoting
v0.3.0; all six instances report0.3.0. The Kargo details come fromkubernetes/polkadot-rest-api-kargo/templates/{warehouse,stage}.yamlandkubernetes/00-appset/values-products.yaml, and the URL fromkubernetes/kargo/values-parity-mgmt.yamland the SRE app deploy runbook.