Should sjb/hack/determine_install_upgrade_version.py ever return an upgrade version that is not the search version?

[stevekuznetsov]

@jhadvig one of the side-effects of the issues today was that I noticed that sjb/hack/determine_install_upgrade_version.py is returning something other than the input package version for the upgrade target. When does this make sense? I thought we always want to upgrade to the code we just built, right? Maybe I am forgetting something in the history of this script :\

[jhadvig]

@stevekuznetsov so the only case that this could occure is that we are building a pre-release upgrade version of the built pkg, cause in that case we are using the latest release version that is available, check https://github.com/openshift/aos-cd-jobs/blob/master/sjb/hack/determine_install_upgrade_version.py#L31-L34
True that we want to upgrade to the version that we just built, but I have a strange feeling that we are missing some other edge case.

[jhadvig]

So I think its because of the *_TARGE_BRANCH variables,. If the origin PR is eg. against release-1.5, are we chcking our the matching branch of o-a repo ?

[stevekuznetsov]

I don't think we are.