release: use GitHub's gh to create GitHub release #18649
Conversation
|
Skipping CI for Draft Pull Request. |
|
@ahrtr, @jmhbnz, @serathius, PTAL :) |
ivanvc
force-pushed
the
use-gh-to-publish-releases
branch
3 times, most recently
from
c498282
to
9ea3c41
Compare
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files
... and 20 files with indirect coverage changes @@ Coverage Diff @@
## main #18649 +/- ##
==========================================
- Coverage 68.80% 68.77% -0.04%
==========================================
Files 420 420
Lines 35494 35494
==========================================
- Hits 24423 24411 -12
- Misses 9646 9661 +15
+ Partials 1425 1422 -3 Continue to review full report in Codecov by Sentry.
|
ivanvc
force-pushed
the
use-gh-to-publish-releases
branch
from
9ea3c41
to
2662ac0
Compare
scripts/release_notes.tpl.txt
Outdated
| @@ -0,0 +1,91 @@ | |||
| Please check out [CHANGELOG](https://github.com/etcd-io/etcd/blob/main/CHANGELOG/CHANGELOG-3.5.md) for a full list of changes. And make sure to read [upgrade guide](https://github.com/etcd-io/website/blob/main/content/en/docs/v3.6/upgrades/upgrade_3_6.md) before upgrading etcd (there may be breaking changes). | |||
There was a problem hiding this comment.
Note; we wanted to simplify the release notes. #15185
There was a problem hiding this comment.
I agree with that issue/improvement, but I'd like to avoid scope creeping this pull request and implementing it by only creating the release with gh. I think it would be a good idea to create an umbrella issue for the improvements we want to make to the release process. I'll note this and create it when I close some of the tasks I currently have open.
There was a problem hiding this comment.
We can do it separately. This PR only focuses on automating the creating github release.
Should we create separate templates for each release (including 3.5.x, 3.4.x and 3.6.x)? @ivanvc Since this PR is for the main branch, we can resolve it in followup PR if you want.
There was a problem hiding this comment.
Ah, good point. I didn't realize that it has mixed links from 3.5 and 3.6 in the release notes. I'll work on it in this PR.
ivanvc
force-pushed
the
use-gh-to-publish-releases
branch
2 times, most recently
from
2926962
to
f44983c
Compare
k8s-ci-robot
added
the
github_actions
ivanvc
force-pushed
the
use-gh-to-publish-releases
branch
from
f44983c
to
3e9e654
Compare
|
/retest |
ivanvc
force-pushed
the
use-gh-to-publish-releases
branch
2 times, most recently
from
fb3f41d
to
17929b7
Compare
|
I updated the script. It's a bit difficult to test it out locally. We could bring more improvements later on. A sample release is the following: https://github.com/ivanvc/etcd/releases/tag/untagged-1dc492de524109e605b4 |
|
/retest |
Signed-off-by: Ivan Valdes <[email protected]>
ivanvc
force-pushed
the
use-gh-to-publish-releases
branch
from
17929b7
to
88d2d24
Compare
|
/retest |
ivanvc
changed the title
|
/test pull-etcd-integration-1-cpu-amd64 |
| # should be left without any additional mark (therefore, it doesn't need a special argument). | ||
| if [ "${BRANCH}" = "main" ]; then | ||
| gh_release_args=(--prerelease) | ||
| elif [ "${BRANCH}" = "release-3.5" ]; then |
There was a problem hiding this comment.
What happens when we release 3.6, and this will not updated? Maybe we should assert that branch name and fail that if new branch is cut we need to update which is the latest?
| fi | ||
|
|
||
| if [ "${REPOSITORY}" = "$(pwd)" ]; then | ||
| gh_repo=$(git remote get-url origin) |
There was a problem hiding this comment.
This assumes that people cloned etcd main repo. If they cloned fork the origin would point to it. Is there any reason we cannot just skip it?
| fi | ||
|
|
||
| gh_repo=$(echo "${gh_repo}" | sed 's/^[^@]\+@//' | sed 's/https\?:\/\///' | sed 's/\.git$//' | tr ':' '/') | ||
| log_callout "Creating GitHub release for ${RELEASE_VERSION} on ${gh_repo}" |
There was a problem hiding this comment.
Do we really want to support pushing to other repositories?
There was a problem hiding this comment.
Re: this comment and #18649 (comment). I understand that we may want to drop supporting other repositories to simplify the process. However, the only reason I'd like to keep it, is that it's the only way to test locally without doing a release in etcd-io's repository (i.e., https://github.com/ivanvc/etcd/releases).
There was a problem hiding this comment.
I like the ability to test in forks, let's keep it imo.
There was a problem hiding this comment.
I like the ability to test in forks, let's keep it imo.
+1
Also it's just creating a draft release, and isn't published yet. It needs the release person to manually publish it.
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ahrtr, ivanvc, jmhbnz, serathius The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
ivanvc
added
backport/v3.4
backport/v3.5
github_actions
|
/cherrypick release-3.5 |
|
@ivanvc: #18649 failed to apply on top of branch "release-3.5": In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Backport pull request etcd-io#18649. Signed-off-by: Ivan Valdes <[email protected]>
Backport pull request etcd-io#18649. Signed-off-by: Ivan Valdes <[email protected]>
Backport pull request etcd-io#18649. Signed-off-by: Ivan Valdes <[email protected]>
Backport pull request etcd-io#18649. Signed-off-by: Ivan Valdes <[email protected]>
Backport pull request etcd-io#18649. Signed-off-by: Ivan Valdes <[email protected]>
Backport pull request etcd-io#18649. Signed-off-by: Ivan Valdes <[email protected]>
Implements #18604.
While we verify that this works as expected, it will create the release as a draft. Then, we can verify that it looks correct and manually publish them.
I tested this feature in my fork. Refer to the latest release (and its assets).
I introduced a
scripts/release_notes.tpl.txt. Because I don't have access to edit a previous release and copy the Markdown, I manually crafted the Markdown based on what I saw and improved how we reference the version for the Docker instructions. But, because it was manual, I may have an error.While working on importing the release notes, I realized that we had been copy-pasting the release text with a broken link.
Please read https://github.com/etcd-io/etcd/blob/main/CONTRIBUTING.md#contribution-flow.