USHIFT-1349: automatically track pre-release versions in release note script #3163
Conversation
|
@dhellmann: This pull request references USHIFT-1349 which is a valid jira issue. 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 openshift-eng/jira-lifecycle-plugin repository. |
openshift-ci-robot
added
the
jira/valid-reference
openshift-ci
bot
added
the
approved
| # 4.16 | ||
| version = version_makefile.read_text('utf8').split('=')[-1].strip().split('.')[:2] |
There was a problem hiding this comment.
Is the version a list? Looks like it due to [:2] and usage in line 136, but comment 4.16 suggests it's a str.
Do you think we could make some changes to have less list operations? Could we add a struct {major, minor} or at least major minor integers? All that [idx] (together with line 136) is a bit difficult to read
There was a problem hiding this comment.
Yeah, this could be written clearer. Maybe even as a regex. :-)
The comment is wrong here. version ends up a list, and then versions_to_scan below gets 2 strings.
I'll fix this up.
| if not args.versions_to_scan: | ||
| args.versions_to_scan = versions_to_scan |
There was a problem hiding this comment.
What's this for? I don't see args passed to another fuction and I don't see usage of args.versions_to_scan
There was a problem hiding this comment.
I think this is a vestige of an earlier implementation plan that I didn't follow..
There was a problem hiding this comment.
Actually, it was mistakenly trying to replace the defaults with the values the user gave us, but I either overwrote the wrong variable or passed the wrong variable to all of the functions that need it below.
| root_dir = pathlib.Path(__file__).parent.parent.parent | ||
| version_makefile = root_dir / 'Makefile.version.aarch64.var' |
There was a problem hiding this comment.
Can't we assume we're executing the script from the microshift/ and just use current working dir? That's how it runs in the https://github.com/openshift/release/pull/49830/files#diff-24ec5dd51fc1cbf37ac7d08f85d9f4d8abc188083abce1ccc7ace59d1eaf6377R16-R17
Scratch that, it's gen_ec_release_notes.sh calling this script with full absolute path
dhellmann
force-pushed
the
USHIFT-1349-automate-version-limits-release-notes
branch
from
b6ae754
to
e5967c3
Compare
… script We build a default list of versions to scan using the current version and the previous version. This assumes the script is run out of the main branch where we can find the most current version under development. During the period where 4.n is being developed, 4.n-1 may still be producing only release candidates, so that scanning those 2 versions give us the 2 most recent candidates for having no releases. During the period where the main branch has not landed a rebase to update the version and both main and the pre-release branch have the same version, we will end up scanning for EC or RC releases of 4.n-2, but that's
dhellmann
force-pushed
the
USHIFT-1349-automate-version-limits-release-notes
branch
from
e5967c3
to
935cfc8
Compare
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dhellmann, pmtk 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 |
|
@dhellmann: all tests passed! Full PR test history. Your PR dashboard. 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/test-infra repository. I understand the commands that are listed here. |
We build a default list of versions to scan using the current version
and the previous version. This assumes the script is run out of the
main branch where we can find the most current version under
development. During the period where 4.n is being developed, 4.n-1 may
still be producing only release candidates, so that scanning those 2
versions give us the 2 most recent candidates for having no
releases. During the period where the main branch has not landed a
rebase to update the version and both main and the pre-release branch
have the same version, we will end up scanning for EC or RC releases
of 4.n-2, but that's
/assign @pmtk @pacevedom