CoreDNS 1.11.2 Release

[chrisohaver]

CoreDNS 1.11.2 Release

[jeremyrickard]

@chrisohaver do you all need assistance working through the publishing/release issue? could we consider migrating to publish to GitHub container registry instead.

That would be something consumers would need to adapt to but would probably be less maintenance in terms of future releases and management of docker secrets.

[cdalvaro]

Do you have considered using GitHub Container Registry?

It would be a great addition in order to avoid Docker pull quota limitation

[BenTheElder]

The go1.21.8 / 1.22.1 CVE patches seem like something worth picking up https://groups.google.com/g/golang-dev/c/o1I1Vv8Rfgs/m/Wr8tD1RlAgAJ

[s3than]

Would it be possible to delete the tag for 1.11.2?

It's flagging as a release in a few tools

[SuperQ]

Here's the current list of non-chore changes:

• plugin/rewrite: add rcode as a rewrite option by @pschou in #6204
• Handle UDP responses that overflow with TC bit by @SriHarsha001 in #6277
• Use the correct root domain name in the proxy plugin's TestHealthX tests by @tmthrgd in #6395
• plugin/cache: key cache on Checking Disabled (CD) bit by @gcs278 in #6354
• plugin/etcd: the etcd client adds the DialKeepAliveTime parameter by @journey-c in #6351
• plugin/auto: warn when auto is unable to read elements of the directory tree by @chrisohaver in https://github.com/c
  oredns/coredns/pull/6333
• plugin/tls: respect the path specified by root plugin by @mariuskimmina in #6138
• rewrite: fix multi request concurrency issue in cname rewrite by @Amila-Rukshan in #6407

[berks-slack]

Is there an estimated date on this? There are quite a few dependency vulnerabilities in 1.11.1

[pacoxu]

missing image coredns/coredns:1.11.2

https://github.com/coredns/coredns/actions/runs/8084880918 the release CI failed.
@chrisohaver

[chrisohaver]

I suspect the original failure was due to a password change.
And the failures after moving to a new account I suspect due to special characters present in the password getting mangled by make.

Just suspicion since I don't know the actual passwords.

[chrisohaver]

I can retag the original 1.11.2 commit without a release if that helps people not be confused. Or maybe that would be more confusing? I don’t know. Let me know folks. What do you all want.

[chrisohaver]

well that didn't work. the release workflow failed when trying to create the tag.

[chrisohaver]

Thanks - no tag protection rules in place, and per https://github.com/softprops/action-gh-release?tab=readme-ov-file#permissions, only "write" is required, which we have set.

I'm wondering if it's something like dangling references to the old tag that GitHub fails to clean up after a tag deletion preventing a tag with the same name being created again. If so, then v1.11.2 may forever be cursed and we need to move on to v1.11.3.

[tedaford]

That's what's happening.

[SuperQ]

It looks like we have a bunch of golangci-lint issues to fix.

[chrisohaver]

Yes, they've been failing I think since November.

[chrisohaver]

I suspect perhaps a change in the linter?

[Tantalor93]

oh I think I know, why it fails, this should fix it #6456
usually Dependabot pull requests failed due to conflict in cache of setup-go and golangci-lint action

[cattyhouse]

what about this :
#6069

[jason-bivins]

Hey, we have a few customers waiting on the UDP overflow fix. Is there an ETA for the release yet?

[chrisohaver]

The docker build/publish has failed due to authentication failure (in 2 attempts).

[chrisohaver]

I do not have push access to the coredns docker hub repo, so I cannot resolve the docker push auth failure.

[chrisohaver]

Update: we tried replacing the docker creds with known working set, and we continue to see the same build failure - an authentication failure when attempting to push the images to dockerhub. Get "https://registry-1.docker.io/v2/": unauthorized: incorrect username or password

[zhangguanzhang]

missing image coredns/coredns:1.11.2

[chrisohaver]

Aware

[chrisohaver]

I have deleted the 1.11.2 release so we don’t have a 1/2 completed release. Will re-release once docker login issue is resolved.

[chrisohaver]

Docker login issue doesn't appear to have progressed.

Is anyone with coredns docker write permissions quietly working on this?

If not, perhaps we should consider moving away from dockerhub and publishing to gcr instead?

[jason-bivins]

hey @chrisohaver, if you're using Docker Desktop can you file a ticket here https://hub.docker.com/support/desktop ? If not, send an email to [email protected] so we can help you get the hub credentials issue resolved?
It looks like the last user that pushed was one of the owners of the coredns organization in docker hub
https://hub.docker.com/r/coredns/coredns/tags

[robbiezhang]

@chrisohaver, is there a release branch/tag we can check if all security patches are included in v1.11.2.

[chrisohaver]

@chrisohaver, is there a release branch/tag we can check if all security patches are included in v1.11.2.

It will be cut from whatever the latest commit of the master branch is when we release it.

[robbiezhang]

@chrisohaver, is there a release branch/tag we can check if all security patches are included in v1.11.2.

It will be cut from whatever the latest commit of the master branch is when we release it.

Thanks for the reply. Would you consider having a formal release branch(es) and schedule (monthly or quarterly release) for CoreDNS? There are quite a lot CVEs exploited recently, we'll need to address them ASAP.

[chrisohaver]

There's an open proposal in process to support release branches - one of the open PRs open currently. However, that doesn’t really relate to the unresolved build publishing issue.

[chrisohaver]

Any help is appreciated! Thanks!
I'm not opposed to moving to gcr.

[cdalvaro]

Any help is appreciated! Thanks! I'm not opposed to moving to gcr.

Here is the documentation for publishing images to ghcr: https://docs.github.com/en/actions/publishing-packages/publishing-docker-images#publishing-images-to-github-packages

Maybe the easiest way is to prepend ghcr.io/coredns/ to the image name, so the final name is: ghcr.io/coredns/coredns:tag, and login into GitHub Container Registry. That way docker push will push images to GitHub Container Registry.

However, if you want to still pushing images to Docker Hub, more work should be done.

[max-allan-cgr]

@chrisohaver do you know if the release will still be called 1.11.2 or will it skip to 1.11.3?

(And will it be soon? Not trying to put pressure on you to get it done, but an ETA of when you think it could be done would be useful. If you're busy say "a month" it's fine!)

[chrisohaver]

@chrisohaver do you know if the release will still be called 1.11.2 or will it skip to 1.11.3?

What do you think would be least painful and confusing for everyone? I’m not sure.

(And will it be soon?…

maybe? Will try a release again later this week with recent build fix if no other maintainers do.

[max-allan-cgr]

Myself, I'd prefer 1.11.3. There seems to be a bit more going into this release than was in the original 1.11.2, so it does make sense to up-version.

[chrisohaver]

Ok. We can close this and open a 1.11.3 release tracking issue.

[chrisohaver]

I'm going to try to do a release the originally attempted commit 01bded8

And then try to the docker build with latest fixes on that tag.

Will see how that goes. 🤞

[chrisohaver]

Symptoms the same as this issue: softprops/action-gh-release#411

[chrisohaver]

still failing

[chrisohaver]

still failing

To clarify: The tag&release step of the release script is failing. The docker publish step is not executed because that process happens after a successful tag&release. The failures from a few weeks ago were in the docker publish step. The failure in the tag&release step is a new development.

[tedaford]

Try poking at your tag protection rules. Or, if you want to see if it's a permissions issue, maybe try permissions: write-all , scoped to the specific failing job.
It's been a few years, but I want to say I had to give my token more permissions than I first assumed, when setting up a CI pipeline to cut Github releases

[networkhermit]

I managed to get the action-gh-release printing some debug information running from my fork:

https://github.com/bikesheddev/coredns/actions/runs/8619349018/job/23623824499#step:6:17

👩‍🏭 Creating new GitHub release for tag v1.11.2 using commit "01bded8194be73ce4601ad608a0464166cee932a"...
⚠️ GitHub release failed with status: 403
HttpError: Resource not accessible by integration
retrying... (2 retries remaining)
👩‍🏭 Creating new GitHub release for tag v1.11.2 using commit "01bded8194be73ce4601ad608a0464166cee932a"...
⚠️ GitHub release failed with status: 403
HttpError: Resource not accessible by integration
retrying... (1 retries remaining)
👩‍🏭 Creating new GitHub release for tag v1.11.2 using commit "01bded8194be73ce4601ad608a0464166cee932a"...
⚠️ GitHub release failed with status: 403
HttpError: Resource not accessible by integration
retrying... (0 retries remaining)
❌ Too many retries. Aborting...
Error: Too many retries.

I don't know the root cause of this error. But using the master commit or my tmp commit as workflow input works:

https://github.com/bikesheddev/coredns/actions/runs/8619437305/job/23624118432

https://github.com/bikesheddev/coredns/actions/runs/8619449474/job/23624161952

I suggest to use another tag/commit for release.

Edited:

Set permissions: write-all doesn't work:

https://github.com/bikesheddev/coredns/actions/runs/8626020717/job/23643835286

[orsenthil]

Since this issue related to a broken tag, should a new release be made from 1.11.3?
Creating this early release will help us the upstream k8s can be use 1.11.3 for the K8s 1.31 before the release freeze timeline.

[BenTheElder]

[ connecting the dots ... 1.11.3 is tracked in #6638 ]

P.S. thank you all, coreDNS is great :-)

[fcolista]

Any update on this?

[tedaford]

Not yet. The version bump PR was merged, now a new release has to be "cut". So, any time now, a new release should happen