Skip to content
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

updatecli: add typefilter latest: true #6371

Assignees

Comments

@mgfritch
Copy link
Contributor

We need to ensure UpdateCli is choosing the tagged latest release,
instead of creating PRs that actually bump the version backward by
selecting the most recent chronological release

See also: rancher/image-build-node-feature-discovery#35

@mgfritch mgfritch self-assigned this Jul 18, 2024
mgfritch added a commit to mgfritch/image-build-ib-sriov-cni that referenced this issue Jul 18, 2024
Ensure UpdateCli chooses the tagged `latest` release,
instead of choosing the most recent chronological release

Fixes: rancher/rke2#6371
Signed-off-by: Michael Fritch <[email protected]>
mgfritch added a commit to mgfritch/image-build-node-feature-discovery that referenced this issue Jul 18, 2024
Ensure UpdateCli chooses the tagged `latest` release,
instead of choosing the most recent chronological release

Fixes: rancher/rke2#6371
Signed-off-by: Michael Fritch <[email protected]>
mgfritch added a commit to mgfritch/image-build-sriov-network-device-plugin that referenced this issue Jul 18, 2024
Ensure UpdateCli chooses the tagged `latest` release,
instead of choosing the most recent chronological release

Fixes: rancher/rke2#6371
Signed-off-by: Michael Fritch <[email protected]>
mgfritch added a commit to mgfritch/image-build-sriov-network-device-plugin that referenced this issue Jul 18, 2024
Ensure UpdateCli chooses the tagged `latest` release,
instead of choosing the most recent chronological release

Fixes: rancher/rke2#6371
Signed-off-by: Michael Fritch <[email protected]>
mgfritch added a commit to mgfritch/image-build-sriov-network-resources-injector that referenced this issue Jul 18, 2024
Ensure UpdateCli chooses the tagged `latest` release,
instead of choosing the most recent chronological release

Fixes: rancher/rke2#6371
Signed-off-by: Michael Fritch <[email protected]>
mgfritch added a commit to mgfritch/image-build-sriov-operator that referenced this issue Jul 18, 2024
Ensure UpdateCli chooses the tagged `latest` release,
instead of choosing the most recent chronological release

Fixes: rancher/rke2#6371
Signed-off-by: Michael Fritch <[email protected]>
mgfritch added a commit to mgfritch/image-build-sriov-operator that referenced this issue Jul 18, 2024
Ensure UpdateCli chooses the tagged `latest` release,
instead of choosing the most recent chronological release

Fixes: rancher/rke2#6371
Signed-off-by: Michael Fritch <[email protected]>
mgfritch added a commit to mgfritch/image-build-whereabouts that referenced this issue Jul 18, 2024
Ensure UpdateCli chooses the tagged `latest` release,
instead of choosing the most recent chronological release

Fixes: rancher/rke2#6371
Signed-off-by: Michael Fritch <[email protected]>
mgfritch added a commit to rancher/image-build-flannel that referenced this issue Jul 18, 2024
Ensure UpdateCli chooses the tagged `latest` release,
instead of choosing the most recent chronological release

Fixes: rancher/rke2#6371
Signed-off-by: Michael Fritch <[email protected]>
mgfritch added a commit to rancher/image-build-coredns that referenced this issue Jul 18, 2024
Ensure UpdateCli chooses the tagged `latest` release,
instead of choosing the most recent chronological release

Fixes: rancher/rke2#6371
Signed-off-by: Michael Fritch <[email protected]>
mgfritch added a commit to rancher/image-build-multus that referenced this issue Jul 18, 2024
Ensure UpdateCli chooses the tagged `latest` release,
instead of choosing the most recent chronological release

Fixes: rancher/rke2#6371
Signed-off-by: Michael Fritch <[email protected]>
@olblak
Copy link
Member

olblak commented Jul 18, 2024

@mgfritch If you are sure that the version to monitor is always following semantic versioning then it would be better to use something like

sources:
 multus:
   name: Get multus version
   kind: githubrelease
   spec:
     owner: k8snetworkplumbingwg
     repository: multus-cni
     token: '{{ requiredEnv .github.token }}'
     typefilter:
       release: true
       draft: false
       prerelease: false
     versionfilter:
       kind: semver

The reason is because the version "latest" version means different things depending on the context.
In the case of GitHub release, it means latest by published date, so project maintaining multiple release line at the same time will make it harder to stay on the same release line.

You could enforce this by specifying you are looking for the latest from a semver point of vue and you could also have version pattern like

sources:
 multus:
   name: Get multus version
   kind: githubrelease
   spec:
     owner: k8snetworkplumbingwg
     repository: multus-cni
     token: '{{ requiredEnv "UPDATECLI_GITHUB_TOKEN" }}'
     typefilter:
       release: true
       draft: false
       prerelease: false
     versionfilter:
       kind: semver
       pattern: "~3"

@mgfritch
Copy link
Contributor Author

mgfritch commented Jul 23, 2024

Hey, thanks @olblak ! 👋

Generally, we select a release based on what's tagged as the latest (stable) upstream and then package/validate this release via our downstream chart(s).

Your first semver example appears to accomplish that, but we'd also like to see UpdateCli open a separate PR for each of these version bumps, instead of amending to an existing PR.

I'm a little unclear on the documentation, but maybe this can be accomplished by setting workingbranch: true on the git scm ?

@olblak
Copy link
Member

olblak commented Jul 23, 2024

Generally, we select a release based on what's tagged as the latest (stable) upstream and then package/validate this release via our downstream chart(s).

It makes sense

I'm a little unclear on the documentation, but maybe this can be accomplished by setting workingbranch: true on the git scm ?

workingbranch=false allows you to commit directly to the targeted branch like main without using a working branch.
for historical reason and to not introduce breaking changes, the git scm has workingbranch set to false by default while all other scm (github,gitea,etc) set to true

I usually advance to not commit to a directly to the main branch without some sort of validation because then you put a lot of trust on that upstream dependency maintainer

we'd also like to see UpdateCli open a separate PR for each of these version bumps, instead of amending to an rancher/image-build-node-feature-discovery#35

I don't see a way to achieve that in the current situation.
I must admit it's a scenario I never considered, why would you prefer a different pull request?

@mgfritch
Copy link
Contributor Author

we'd also like to see UpdateCli open a separate PR for each of these version bumps, instead of amending to an rancher/image-build-node-feature-discovery#35

I don't see a way to achieve that in the current situation. I must admit it's a scenario I never considered, why would you prefer a different pull request?

Using the attached PR as an example, we could have merged the one desired pull request while closing out any additional undesired pull requests ...

However, maybe that would be a moot issue if we had used the semver versionfilter, because the pull request would have been updated iff there was a matching semver release greater than the release posted in the open PR?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment