After a bit more digging, I found that it wasn't necessary to pass in the GitHub issue id to some of the scripts. This should make it even easier to follow the daily (primarily Friday) task list.
The catch is the math to get the issue id is we are looking for an issue that has a release label (set in the create script). We need to make sure that there is never more than one open issue that has a release label. I did limit the return to just 1, but if there are multiple, it's going to grab the most current, even if that's not the one you want. This probably isn't a huge deal because only one person should be doing the release, so that's why I didn't go overboard with protections.
Testing done
Ran scripts to verify.
Submitter checklist
[x] Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
[x] Ensure that the pull request title represents the desired changelog entry
[x] Please describe what you did
[x] Link to relevant issues in GitHub or Jira
[x] Link to relevant pull requests, esp. upstream and downstream changes
[x] Ensure you have provided tests - that demonstrates feature works or fixes the issue
After a bit more digging, I found that it wasn't necessary to pass in the GitHub issue id to some of the scripts. This should make it even easier to follow the daily (primarily Friday) task list.
The catch is the math to get the issue id is we are looking for an issue that has a
releaselabel (set in the create script). We need to make sure that there is never more than one open issue that has areleaselabel. I did limit the return to just 1, but if there are multiple, it's going to grab the most current, even if that's not the one you want. This probably isn't a huge deal because only one person should be doing the release, so that's why I didn't go overboard with protections.Testing done
Ran scripts to verify.
Submitter checklist