[3.4] fix release.sh: git_assert_branch_in_sync not exist in 3.4 #15715
Conversation
Signed-off-by: Benjamin Wang <wachao@vmware.com>
ahrtr
force-pushed
the
fix_release_20230414
branch
from
52aa5e4
to
46c6ea5
Compare
|
cc @serathius PTAL |
|
Should we backport |
| @@ -6,7 +6,7 @@ source ./scripts/test_lib.sh | |||
|
|
|||
| VER=$1 | |||
| PROJ="etcd" | |||
| REPOSITORY="${REPOSITORY:-git@github.com:etcd-io/etcd.git}" | |||
| REPOSITORY="${REPOSITORY:-https://github.com/etcd-io/etcd.git}" | |||
There was a problem hiding this comment.
Note that also applies on other branches. Not as important for this PR.
I prefer git@github.com:etcd-io/etcd.git as during push I can depend on SSH security instead of typing in credentials. It's much safer. Best would be to take address of origin remote from original repo.
There was a problem hiding this comment.
I agree. But in 3.4, actually I never depend on the automatically git push. Instead, each time, I manually bump the version and create/push the tag.
Let's just keep it as it was. It was working well previous. After the 49d05f8, it broke the 3.4 release, so I tend to partially revert the change.
We can consider to enhance it later; but I don't expect to make much big change on 3.4.
|
thx @serathius I will not allow any release script change anymore in future, so as not to break it again. Because usually our workflow/pipeline will never test the real release execution path. |
The
git_assert_branch_in_syncdoesn't exist in 3.4, so let's just remove it.The issue was introduced in 49d05f8. In our workflow, it always run in
in-placemode, so it never triggers the branch.