New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
.github: set link for GH issue feature template #17214
Conversation
To check for backport PRs we should check the label backport/1.X. Signed-off-by: André Martins <andre@cilium.io>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the "backports" keyword search not work?
Originally I avoided setting it like is proposed here because label:backport/1.X
is guaranteed to link to an empty result, and we typically do releases for multiple branches at the same time so it doesn't matter if the filter catches more than the specific branch.
That said, if this works better for you then I'm OK with merging it.
No, look at the difference between the 2 search results: What I usually do is search and replace it automatically with a bash function that is something like: gen_release_template(){
# change to Cilium directory first
local major="${1}"
local minor="${2}"
local patch="${3}"
local next_patch="$(( ${patch} + 1 ))"
sed "s/1.X/${major}.${minor}/g;s/X.Y.Z/${major}.${minor}.${patch}/g;s/X.Y.W/${major}.${minor}.${next_patch}/g;s/X.Y/${major}.${minor}/g" .github/ISSUE_TEMPLATE/release_template.md | xclip -selection c
} then for example |
Can we put that somewhere in |
Actually minor hack on top, I just integrated this into my local scripts:
This way I can just go into the worktree for an older release and run it without worrying about which version, and it will pick the right one. |
To check for backport PRs we should check the label backport/1.X.
Signed-off-by: André Martins andre@cilium.io