No Docker images for 1.11+
xrstf opened this issue · comments
Since v1.12, the git tags are not annotated anymore. This may be the reason why there are no container images available for 1.12 and 1.13. Is this intended?
Thanks for filing this!
That's not at all intended.
I think v1.12 and v1.13 are annotated though. Accidentally, I did not annotate v1.10 and v1.11. But didn't expect it to make a difference in the docker tags.
I'll investigate and report back.
Looking at the gitlab registry and dockerhub, the last tag in both is v1.10.
They're supposed to happen automatically as part of the CI pipeline.
After v1.10, I moved the docker pipeline from Gitlab CI to Github Actions. It seems that during that migration, I broke the automatic tagging.
In Gitlab, I used $CI_COMMIT_REF_NAME. And when moving that to Github, I used $GITHUB_REF_NAME.
Documentation for $GITHUB_REF_NAME says:
The short ref name of the branch or tag that triggered the workflow run. This value matches the branch or tag name shown on GitHub.
So at first glance, it should be working? I'll investigate more, but at least the point where things stopped working match the migration to Github Actions, so it's likely the bug is in the new docker workflow config.
I don't see Github Actions being run for the tag pushes themselves at all. So looking into it, it seems that they need to be configured explicitly.
I also found this similar question, which has essentially that same answer.
I think that's the root of the problem.
I think commit 30c286f fixes the issue.
To validate this, I allowed the docker workflow to run on test tags in the config (as seen in the commit), and then tagged it test-tag-20240203-01.
Github Actions proceeded to run for it, and now both registries show the correctly tagged images.
I subsequently deleted the test tag from github to avoid confusion.
Since the master branch is currently at v1.13, I managed to push tag v1.13 manually to dockerhub.
I could rebuild v1.11 and v1.12 locally and push those. However I'm not sure if at this point it's worth the trouble, and also might end up causing more confusion.
I can't log in to Gitlab registry for some mysterious reason, apparently it is knowingly difficult to understand why it fails, but it could be an IP block or a rate limiting problem.
So I can't tag v1.13 in Gitlab right now. I will retry tomorrow (in case it's a rate limiting issue); otherwise, as much as I want to support more than one hosting platform, in this case their bad tooling is getting in the way.
Please let me know if you have an opinion on either thing; and again thanks for reporting this!
Hopefully this should be "fixed enough" with v1.13 being in dockerhub, and new releases from now on should be automatically tagged as they were before.
Thanks, for me personally the upstream images you provide do not matter that much, as they include Dovecot and too much extra logic, so I'm building my own images (also to include the DKIM tools and my own LDA).
"Proper" tags would however in the future allow me to go install chasquid@vX.Y again, currently I have to go install using the git commit hash instead.
Thanks, for me personally the upstream images you provide do not matter that much, as they include Dovecot and too much extra logic, so I'm building my own images (also to include the DKIM tools and my own LDA).
Got it, thanks for letting me know!
"Proper" tags would however in the future allow me to
go install chasquid@vX.Yagain, currently I have togo installusing the git commit hash instead.
You mean "annotated" tags? chasquid v1.12 and v1.13 tags are both annotated, so again I suspect that problem isn't about annotated vs lightweight tags.
And look:
$ go version
go version go1.21.6 linux/amd64
$ for i in v1.7 v1.8 v1.9 v1.10 v1.11 v1.11.1 v1.12 v1.13; do echo $i `go install -v blitiri.com.ar/go/chasquid@$i 2>&1`; done
v1.7 go: blitiri.com.ar/go/chasquid@v1.7: no matching versions for query "v1.7"
v1.8 go: blitiri.com.ar/go/chasquid@v1.8: no matching versions for query "v1.8"
v1.9 go: blitiri.com.ar/go/chasquid@v1.9: no matching versions for query "v1.9"
v1.10 go: blitiri.com.ar/go/chasquid@v1.10: no matching versions for query "v1.10"
v1.11
v1.11.1
v1.12 go: blitiri.com.ar/go/chasquid@v1.12: no matching versions for query "v1.12"
v1.13 go: blitiri.com.ar/go/chasquid@v1.13: no matching versions for query "v1.13"
I tried with go 1.19.8 and had the same result.
So my theory for this behaviour is that since I published v1.11.1 recently, there is some heuristic in the tooling that now expects a 3-component version.
You can see that pkg.go.dev's chasquid versions only shows v1.11.1.
This is a good reason to start numbering releases with a "0" patch level, so there's less friction with tooling that expects a full semver.
Annotated vs. lightweight was my guess when I saw only 2 commits in
that had an annotation on it. But if you were able to go-install v1.10, then I'm also confused as to what's happening.
I'm not super good with vanity URLs, but looking at thosefor chasquid:
<meta name="go-import"
content="blitiri.com.ar/go/chasquid git https://blitiri.com.ar/repos/chasquid" />
<meta name="go-source"
content="blitiri.com.ar/go/chasquid https://blitiri.com.ar/p/chasquid https://blitiri.com.ar/git/r/chasquid/b/master/t/{dir} https://blitiri.com.ar/git/r/chasquid/b/master/t/{dir}/f={file}.html#line-{line}" />
I wonder: https://blitiri.com.ar/repos/chasquid does return a 404. Is this intended? Yet even
GOPROXY=direct GONOSUMDB=blitiri.com.ar,github.com go install -v blitiri.com.ar/go/chasquid@v1.13
doesn't work, while it works for go-installing 1.11.1, so my theory about the broken URL is probably untrue as well.
Also, on your git server, it seems as if the v1.13 and v1.12 tags at least are annotated. Did you redo those tags or did the github sync somehow skip the tag message?
https://go.dev/blog/publishing-go-modules at least mentions that semvers are always major.minor.patch, so there might not be a "heuristic that now requires all tags beyond 1.11.1 to be of that format", but rather go has always just accepted M.M.P versions. You could try tagging v1.13.0?
Annotated vs. lightweight was my guess when I saw only 2 commits in
[...]
that had an annotation on it. But if you were able to go-install v1.10, then I'm also confused as to what's happening.
It's the other way: v1.10 and v1.11 were not annotated (by accidental oversight from my part). All other tags are annotated.
I'm not super good with vanity URLs, but looking at thosefor chasquid:
[...]
I wonder:https://blitiri.com.ar/repos/chasquiddoes return a 404. Is this intended? Yet evenGOPROXY=direct GONOSUMDB=blitiri.com.ar,github.com go install -v blitiri.com.ar/go/chasquid@v1.13doesn't work, while it works for go-installing 1.11.1, so my theory about the broken URL is probably untrue as well.
Thank you for looking! I think it's not a vanity URL problem, those seem to work just fine.
Also, on your git server, it seems as if the v1.13 and v1.12 tags at least are annotated. Did you redo those tags or did the github sync somehow skip the tag message?
My git server and github are in sync: v1.12 and v1.13 are annotated in both. I think you may be misinterpreting github's UI wrt. what is annotated vs lightweight?
https://go.dev/blog/publishing-go-modules at least mentions that semvers are always major.minor.patch, so there might not be a "heuristic that now requires all tags beyond 1.11.1 to be of that format", but rather go has always just accepted M.M.P versions. You could try tagging v1.13.0?
Could be, but then how did it work for you before? Did it break around the time I released 1.11.1? I never used that "go install @" format with chasquid so I'm assuming it was working because (I thought) you said it was working for you.
But maybe you're right and it was never working in the first place :)
I'll try tagging v1.13.0 later today/tomorrow, will post here when I do.
Thank you for your help in figuring this out!
I tagged v1.13.0 and now go install blitiri.com.ar/go/chasquid@v1.13 works, and pkg.go.dev shows it as the latest version.
I'll just include the patch level in future releases (e.g. just use v1.14.0), as it seems that these days it makes a notable difference in tooling integration.
Unrelated to that, I still can't add a tag to gitlab's docker registry by hand, but at this point I think it's okay to live with it until the next release, considering we haven't had tagged the release images there for >1y.
I'm going to close this as I think all the issues we found during this investigation are now "reasonably fixed", but please reopen and/or comment further if I missed anything!
Thank you!