1.8.5 release tracking #4853
Comments
|
I will take another look to see if there are any remaining items that are needed. |
|
Perhaps #4842. |
Yeah, looks like all other open PRs are pending review/approval, or pending author action. |
There are two new plugins in the release already... In the past we have only bumped minor version for backward compatibility issues, not for new features.
I am (I approved it). But the last commit undid some suggestions that @miekg had made. |
@chrisohaver If #4842 is not to fix a critical bug then I think we can just release 1.8.5 now. And then go with release 1.9.0 to include #4512 and #4842. We don't need to wait too long to release 1.9.0 anyway. If #4842 is a prioritized bug then we can wait for Miek's comments in review getting addressed before 1.8.5 release. |
|
Yes, Let’s just release now, and we can release 1.8.6 soon after if there are any pressing bugs. |
|
Just double-checked: No config backward incompatible changes in the list. One PR deprecated the cache miss metric, but it remains present for metrics backward compatibility. Opened #4857 to update release notes. |
|
With all related PR merged, I will try to trigger a release for 1.8.5 shortly. |
|
/release master 1.8.5 |
|
The command Its standard and error output is |
|
Looks like we hit some issues with the release. Will give it another try, and, hopefully with success. |
|
It likely won't. This is the docker crap we merged if I where to guess
…On Fri, 10 Sep 2021, 17:47 Yong Tang, ***@***.***> wrote:
Looks like we hit some issues with the release. Will give it another try,
and, hopefully with success.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4853 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACWIW2ODHFSZI5R3EEVFWDUBISABANCNFSM5DXRGCLQ>
.
|
|
Possibly this ... #4779 ... |
|
Where are the builds done? |
|
On 'drone'. I'm inclined to remove the entire docker stuff from the release
Makefile or at least split it up. This is the 4th time docker is failing us
…On Fri, 10 Sep 2021, 18:05 chrisohaver, ***@***.***> wrote:
Where are the builds done?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4853 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACWIW6SRGG72OMVJDGJ6DDUBIUELANCNFSM5DXRGCLQ>
.
|
Is it possible that drone updated the container runtime or some component? |
|
Just the usual docker stuff on Debian.
…On Fri, 10 Sep 2021, 18:10 chrisohaver, ***@***.***> wrote:
On 'drone'.
Is it possible that drone updated the container runtime or some component?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4853 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACWIW4S7KA3HH3JEHVBWUTUBIUX5ANCNFSM5DXRGCLQ>
.
|
|
Will it be possible to revert #4779 for now, to get 1.8.5 out first? |
|
FWIW ... In ... docker/for-linux#813 Several people report that restarting docker resolved the same error message. I realize that it's just the same error message text, and not necessarily the same root cause. |
|
Feel free to try, but every docker update restarts it, so machine uptime is
irrelevant.
The docker stuff needs to move out of the release process, it has failed
too many times
…On Fri, 10 Sep 2021, 18:21 chrisohaver, ***@***.***> wrote:
FWIW ... In ... docker/for-linux#813
<docker/for-linux#813>
Several people report that restarting docker resolved the same error
message.
I realize that it's just the same error message text, and not necessarily
the same root cause.
But restarting docker is easy to try, and the box has been up for over 2
years.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4853 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACWIW27YNSTIUJTRFETUTDUBIWA5ANCNFSM5DXRGCLQ>
.
|
I don't think I have root access to drone. Is drone set to auto update docker, or do you occasionally go in and update manually?
Ah, do you mean to no longer produce a container image in coredns/coredns, or to split it out to a separate step? |
|
I can't access drone, ATM. Will check in the weekend.
Yes the docker stuff needs to be a new step, which we call again in the
tracking issue..provided we still care about docker.
…On Fri, 10 Sep 2021, 19:06 chrisohaver, ***@***.***> wrote:
Feel free to try, but every docker update restarts it, so machine uptime
is irrelevant.
I don't think I have root access to drone. Is drone set to auto update
docker, or do you occasionally go in and update manually?
The docker stuff needs to move out of the release process, it has failed
too many times
Ah, do you mean to no longer produce a container image in coredns/coredns,
or to split it out to a separate step?
i.e. do a release of bare binaries, and then later follow up with adding a
containerized version.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4853 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACWIW5W6JGP4E2WBXGG4SLUBI3KBANCNFSM5DXRGCLQ>
.
|
|
We can continue providing docker image. But I would prefer to separate the release so that release process itself will be solely based on tagging the master branch, building binaries, and then upload the binary to GitHub repo release. In other words, a docker image build failure will not block the release. |
I assume that the vast majority of the community use CoreDNS as a container, so providing container image would be in the community interest.
This should be able to be done by modifying the existing webhook on drone to just execute the build, tar, github-push targets. Does the webhook currently accept a commit tag to specify a commit to build on? If it always builds head of master, we'd need to code freeze (no commits to master) between the two steps. |
|
See #4858 and linked PRs to remove docker from
the binary release to github.
|
|
this is I hope the last PR to fix things #4866 Updated the release scripts, so that should work. |
|
/release master 1.8.5 |
|
The command Its standard and error output is |
|
This time, failed uploading the tgz's to GitHub... |
|
curl: (92) HTTP/2 stream 0 was not closed cleanly: CANCEL (err 8)
make: *** [Makefile.release:92: github-push] Error 92
yeah... :-(
looks transient though
|
|
/release master 1.8.5 |
|
The command Its standard and error output is |
|
Eager for next release 😄 Found some conversation re: similar issues -- https://gist.github.com/daofresh/0a95772d582cafb202142ff7871da2fc |
|
/release master 1.8.5 |
|
The command Its standard and error output is |
|
[ Quoting ***@***.***> in "Re: [coredns/coredns] 1.8.5 release..." ]
coredns_1.8.5_darwin_amd64.tgz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
24 13.3M 0 0 24 3392k 0 11.5M 0:00:01 --:--:-- 0:00:01 11.5M
curl: (92) HTTP/2 stream 0 was not closed cleanly: CANCEL (err 8)
hmmm, are _any_ uploads working? Maybe forcing HTTP/1 in curl? --http1.1 option
|
The failures are from the We could try forcing http 1.1, which many people report works. |
|
Actually - looks like the following line is failing to create a RELEASE id... Which then results in a possibly invalid URL path in the curl upload? |
|
[ Quoting ***@***.***> in "Re: [coredns/coredns] 1.8.5 release..." ]
Actually - looks like the following line is failing to create a RELEASE id...
@$(eval RELEASE:=$(shell curl -s -d '{"tag_name": "v$(VERSION)", "name": "v$(VERSION)"}' -H "Authorization: token ${GITHUB_ACCESS_TOKEN}" "https://api.github.com/repos/$(GITHUB)/$(NAME)/releases" | grep -m 1 '"id"' | tr -cd '[[:digit:]]'))
It's empty in the echo in the output (probably should error on that). Then it may
(probably?) be the access token. Which makes sense and which was also updated.
I had however great trouble deciphering github's UI of getting a token specically for
coredns - and as I speak I'm trying the token for users 'miekg' and 'coredns' and that
works
|
|
interesting -- we facing this with a totally different package / where it fails publishing a release to github semantic-release/github#415 |
Regarding re-rolling tokens as result of Codecov getting hacked, I thought that we released 1.8.4 after that. |
|
[ Quoting ***@***.***> in "Re: [coredns/coredns] 1.8.5 release..." ]
Then it may (probably?) be the access token. Which makes sense and which
was also updated.
Regarding re-rolling tokens as result of Codecov getting hacked, I thought that
we released 1.8.4 after that.
If the GitHub token is bad, I think the mode of failure for the release uploads
would be different (e.g. auth failure).
Let me try the curl to get a release id (which doesn't affect the repo) and see what
happens.
|
|
/release master 1.8.5 |
|
The command |
|
Hooray! Now for the docker part... |
|
ok. So... you need to restart caddy when you update the Caddyfile 🤦 |
|
/docker -t 1.8.5 |
|
The command |
|
is this tagging correct? Nope that should be hooray for tracking the releases in issues UPDATE: this is because testing, didn't dare use 'coredns', so used 'x', better named 'test' I guess. |
|
/docker 1.8.5 |
|
The command |
|
coredns.io is updated as well, and I fired off a tweet. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is an issue to track 1.8.5 releases.
One reason for a release is #4834, together with what has already been merged.
PR Enable HTTP/2 in gRPC service #4842/cc @miekg @chrisohaver
The text was updated successfully, but these errors were encountered: