docs(sonic): correct the docker-sonic-vs download instructions - #3731
Open
roc-ops wants to merge 1 commit into
Open
docs(sonic): correct the docker-sonic-vs download instructions#3731roc-ops wants to merge 1 commit into
roc-ops wants to merge 1 commit into
Conversation
Followed the instructions end to end for the first time and downloaded SONiC
202605 build 1166687 with them. The route is right; five things were wrong,
stale or missing:
* the branch example `202405` is two years old. The **vs** pipeline
(definitionId 142) currently offers master, 202605, 202511, 202505, 202411,
202405, 202311 and 202305 -- point at the newest release branch instead.
* *Build History* lists canceled builds next to successful ones, and they have
an **Artifacts** link too, so "latest successful" needs saying more plainly.
The result string in the table is `succeeded`.
* the artifact file list contains **docker-sonic-vs-asan.gz** directly beside
**docker-sonic-vs.gz** -- an AddressSanitizer build, easy to grab by mistake.
* the download URL is constructible from the branch and build ID, which is much
friendlier than scrolling a 1 MB file listing. Documented with a real example.
* `docker load` restores the tag `docker-sonic-vs:latest` -- it does not need
retagging, but it *silently replaces* any existing image with that tag,
printing "renaming the old one with ID ... to empty string". The old text
("retag it to docker-sonic-vs:latest if necessary") got both halves of that
backwards. Added a warning and the tag-first workaround.
Also added the one-liner for checking which build an image is, since that turns
out to matter: `docker run --rm --entrypoint cat docker-sonic-vs:latest
/etc/sonic/sonic_version.yml`.
Verified against the platform table (vs really is at the bottom of the pipeline
list) and by completing the whole download-unpack-load-run sequence.
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.
Follow-up to #3680: the
docker-sonic-vsdownload instructions I wrote in that PR were wrong in several places. I had never actually followed them — the image was already on my test box — so this corrects them after walking the path end to end and pulling SONiC202605build 1166687.The route in the original text was right; five details were not.
202405was given as the example; the current list ismaster,202605,202511,202505,202411,202405,202311,202305.target/docker-sonic-vs-asan.gzsits directly next totarget/docker-sonic-vs.gzin the artifact listing — an AddressSanitizer build, easy to take by mistake.docker loadguidance had both halves backwards. The archive already carriesdocker-sonic-vs:latest, so there is nothing to retag — and more importantly,docker loadsilently replaces an existing image with that tag, printingrenaming the old one with ID ... to empty stringand leaving the previous image untagged. Anyone following the old text to compare two builds would have lost the image they had. That is now a warning with a tag-first workaround.Also adds a one-liner for identifying which build you ended up with (
cat /etc/sonic/sonic_version.yml), which turned out to matter when comparing behaviour between builds.Documentation only — no code, no template, no device changes.