{{ message }}
Repository navigation
Conversation
install-vela.sh took its version from VERSION, which the workflow sets to the image tag. So a tagged build looked for a kubevela release matching the image tag (v1.8.0 has none) and a main build fell back to v1.5.0-beta.6 from 2022. VELA_VERSION now carries the CLI version on its own, defaulting to v1.11.0, and the download uses curl -f so a version with no release fails at the download rather than unpacking an error page. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0162yHyposutJcJjv16HiY1G Signed-off-by: Brian Kane <briankane1@gmail.com>
The job logged into a third registry held in HUB_DOMAIN and died there with a DNS failure, before the build step ran, so nothing has published since v1.7.2 in February 2023. Every other repo in the org publishes to ghcr.io and docker.io only. The ghcr login was already here but its tag had been removed, so the image was pushed to one registry while logging into two. Both tags are now pushed. Also moves off the removed ::set-output command, pins the actions by SHA as the other repos do, and drops the buildkit:master driver pin. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0162yHyposutJcJjv16HiY1G Signed-off-by: Brian Kane <briankane1@gmail.com>
The repo had no CI: registry.yaml was the only workflow and it ran on pushes to main and on tags, so a change to the Dockerfile or the install scripts was first exercised by the release that published it. The existing `push: github.event_name != 'pull_request'` guard was unreachable for the same reason. Pull requests now build linux/amd64 and linux/arm64 without pushing. The registry logins are skipped there, since nothing is published and a fork's run cannot read the secrets. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0162yHyposutJcJjv16HiY1G Signed-off-by: Brian Kane <briankane1@gmail.com>
briankane
force-pushed
the
fix/registry-publish
branch
from
October 16, 2026 14:55
4aa0e1d to
c635dcd
Compare
A pull request run gets GITHUB_REF=refs/pull/N/merge, which the old two-branch version passed through as the tag, and buildx rejected it: invalid tag "docker.io/oamdev/cloudshell:refs/pull/5/merge" Tags, main, pull requests and any other branch now each map to a valid tag. Nothing is pushed on a pull request, but the tag still has to parse. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0162yHyposutJcJjv16HiY1G Signed-off-by: Brian Kane <briankane1@gmail.com>
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
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.
What
The Registry workflow has not published since
v1.7.2in February 2023. Every run dies atLogin KubeVela registry, six seconds in, before the build step:HUB_DOMAINpoints at a registry that no longer resolves. Every other repo in the org publishes to ghcr.io and docker.io only, and has no equivalent step.Changes
Drop the retired registry. Removes the login and its tag. The ghcr.io login was already present but its tag had been removed in 2022, so the job authenticated to two registries and pushed to one. Both tags are now pushed.
Separate the vela CLI version from the image tag.
install-vela.shreadVERSION, which the workflow sets to the image tag, so a tag build looked for a KubeVela release matching the image tag (there is nov1.8.0) and amainbuild fell back tov1.5.0-beta.6from 2022.VELA_VERSIONnow carries it separately, defaulting tov1.11.0. The download usescurl -fso a version with no release fails at the download rather than unpacking an error page.Give the repo CI.
registry.yamlwas the only workflow and ran on pushes to main and on tags, so a Dockerfile change was first exercised by the release that published it. Thepush: github.event_name != 'pull_request'guard was unreachable for the same reason. Pull requests now build both platforms without pushing, with the registry logins skipped since a fork's run cannot read the secrets.Housekeeping. Moves off the removed
::set-outputcommand, pins the actions by SHA as the other repos do, addspackages: write, and drops thebuildkit:masterdriver pin.Verified
Both platforms built locally from this branch:
vela versionttyd --versionrz (lrzsz)For reviewers
Restoring ghcr reverses a deliberate change.
901bfdb Fix: remove ghcrdropped it in August 2022, in the same change that added the registry this PR removes. Putting it back is a judgement call, not a repair, and the login being left behind is what made it look accidental. Happy to ship docker.io only if that is preferred.The first ghcr push may need an org admin.
ghcr.io/kubevela/oamdev/cloudshellwas created in 2022 and I could not check whether that package is linked to this repository. If it is not,GITHUB_TOKENcannot write to it and the package needs connecting to the repo. This only shows at push time.Follow-up, not in this PR
catalog/addons/cloudshell/template.yamlstill pinsoamdev/cloudshell:v1.7.2, so the addon keeps using the 2023 image until that is bumped. That has to merge after this publishes.