-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
feat!: update github-releases
datasource digest computation to use git tag, and preserve existing digest semantics as separate datasource
#20178
feat!: update github-releases
datasource digest computation to use git tag, and preserve existing digest semantics as separate datasource
#20178
Conversation
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.
can we do this in a less breaking way?
eg if there is no digest or the existing digest points to the git sha, use new behavior. if existing digest points to an attachment, use current behavior. fallback to new behavior if current digest can't be found.
I considered doing this, but it felt like this would potentially make things unnecessarily slow, magical and I felt like long-term this might be the best way forward. Happy to make that change if you feel like it |
the problem is, we've a lot users who rely on current behavior. so if we change it without an alternative we would make them very angry about renovate. |
yeah, I see that, but do we actually know that many users rely on this digesting? I haven't seen many issues for this data source, and I would have expected some given the current issues with the digesting. My understanding is that this digest logic was just added for the custom regex manager use-case and other data sources like for Gitlab don't support it either. I don't feel strongly at all though- happy to continue supporting that mechanism |
The last time I looked at this, it seemed like a mistake we should eventually correct. I forget where/why it's being used though - can we revisit that to understand the impact? |
43b4f57
to
26b8b94
Compare
github-releases
datasource getDigest
to consult underlying Git taggithub-releases
datasource digest computation to use git tag, and preserve existing digest semantics as separate datasource
Hi all, I've copied the existing datasource into please let me know if you'd prefer to have this separate PRs. I've kept two commits to make review a little easier. |
github-releases
datasource digest computation to use git tag, and preserve existing digest semantics as separate datasourcegithub-releases
datasource digest computation to use git tag, and preserve existing digest semantics as separate datasource
change to feature. please target v35 branch because of the breaking changes. will try to review later. |
26b8b94
to
c1e8379
Compare
Thanks, done. The CI failures seem to be because 5a6a046 is not part of the |
|
…ebot#19942) Changes `rangeStrategy` default value from `'replace'` to `'auto'`. Changes `auto` behavior so that `update-lockfile` is preferred if the manager supports the `updateLockedDependency()` function. Closes renovatebot#19800 BREAKING CHANGE: Renovate will now default to updating locked dependency versions. To revert to previous behavior, configure rangeStrategy=replace.
…novatebot#19958) Sets new defaults: - `prConcurrentLimit`: 10 (instead of 0) - `prHourlyLimit`: 2 (instead of 0) Closes renovatebot#19800 BREAKING CHANGE: Renovate now defaults to applying hourly and concurrent PR limits. To revert to unlimited, configure them back to `0`.
Set default GOPROXY value to match `go`'s own default. Closes renovatebot#20040 BREAKING CHANGE: Renovate will now use go's default `GOPROXY` settings. To avoid using the public proxy, configure `GOPROXY=direct`.
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.
Sorry, requires another conflict resolution
lib/modules/datasource/github-release-attachments/index.spec.ts
Outdated
Show resolved
Hide resolved
lib/modules/datasource/github-release-attachments/index.spec.ts
Outdated
Show resolved
Hide resolved
Thanks for reviewing & merging. Is there any rough idea when v35 will be around (no promises needed, thx!)? |
…git tag, and preserve existing digest semantics as separate datasource (#20178) Co-authored-by: RahulGautamSingh <[email protected]> Co-authored-by: Rhys Arkins <[email protected]> Co-authored-by: Michael Kriese <[email protected]> Co-authored-by: HonkingGoose <[email protected]>
…git tag, and preserve existing digest semantics as separate datasource (#20178) Co-authored-by: RahulGautamSingh <[email protected]> Co-authored-by: Rhys Arkins <[email protected]> Co-authored-by: Michael Kriese <[email protected]> Co-authored-by: HonkingGoose <[email protected]>
…git tag, and preserve existing digest semantics as separate datasource (#20178) Co-authored-by: RahulGautamSingh <[email protected]> Co-authored-by: Rhys Arkins <[email protected]> Co-authored-by: Michael Kriese <[email protected]> Co-authored-by: HonkingGoose <[email protected]>
…git tag, and preserve existing digest semantics as separate datasource (#20178) Co-authored-by: RahulGautamSingh <[email protected]> Co-authored-by: Rhys Arkins <[email protected]> Co-authored-by: Michael Kriese <[email protected]> Co-authored-by: HonkingGoose <[email protected]>
…git tag, and preserve existing digest semantics as separate datasource (#20178) Co-authored-by: RahulGautamSingh <[email protected]> Co-authored-by: Rhys Arkins <[email protected]> Co-authored-by: Michael Kriese <[email protected]> Co-authored-by: HonkingGoose <[email protected]>
…git tag, and preserve existing digest semantics as separate datasource (#20178) Co-authored-by: RahulGautamSingh <[email protected]> Co-authored-by: Rhys Arkins <[email protected]> Co-authored-by: Michael Kriese <[email protected]> Co-authored-by: HonkingGoose <[email protected]>
…t file digest (#20178) The github-releases datasource has been copied into a new datasource called github-release-attachments. The github-releases general datasource is updated to use the underlying Git tag of a GitHub release entry for digest computation. Fixes #20160, Fixes #19552 BREAKING CHANGE: Regex Manager configurations relying on the github-release data-source with digests will have different digest semantics. The digest will now always correspond to the underlying Git SHA of the release/version. The old behavior can be preserved by switching to the github-release-attachments datasource.
…t file digest (#20178) The github-releases datasource has been copied into a new datasource called github-release-attachments. The github-releases general datasource is updated to use the underlying Git tag of a GitHub release entry for digest computation. Fixes #20160, Fixes #19552 BREAKING CHANGE: Regex Manager configurations relying on the github-release data-source with digests will have different digest semantics. The digest will now always correspond to the underlying Git SHA of the release/version. The old behavior can be preserved by switching to the github-release-attachments datasource.
…t file digest (#20178) The github-releases datasource has been copied into a new datasource called github-release-attachments. The github-releases general datasource is updated to use the underlying Git tag of a GitHub release entry for digest computation. Fixes #20160, Fixes #19552 BREAKING CHANGE: Regex Manager configurations relying on the github-release data-source with digests will have different digest semantics. The digest will now always correspond to the underlying Git SHA of the release/version. The old behavior can be preserved by switching to the github-release-attachments datasource.
Renovate v35 had a breaking change in how it computes the digest of GitHub releses. Previously, it would use the digest of the release attachements, but now it's just using a git sha as the "digest". This commit changes the data source for the Hubble artifacts to use the data source which preserves the old behavior. Ref: renovatebot/renovate#20178 Signed-off-by: Sebastian Wicki <[email protected]>
Renovate v35 had a breaking change in how it computes the digest of GitHub releses. Previously, it would use the digest of the release attachements, but now it's just using a git sha as the "digest". This commit changes the data source for the Hubble artifacts to use the data source which preserves the old behavior. Ref: renovatebot/renovate#20178 Signed-off-by: Sebastian Wicki <[email protected]>
Changes
github-releases
datasource has been copied into a new datasource calledgithub-release-attachments
.github-releases
general datasource is updated to use the underlying Git tag of a GitHub release entry for digest computation.BREAKING CHANGE: Regex Manager configurations relying on the
github-release
data-source with digests will have different digest semantics. The digest will now always correspond to the underlying Git SHA of the release/version. The old behavior can be preserved by switching to thegithub-release-attachments
datasource.Fixes #20160. Fixes #19552.
Context
See: #20160, #19552, and #20175
Currently the
github-releases
datasourcegetDigest
method is rather magical and depends/requires an existing digest and version. This makes it difficult to use in some situations where pinning is enabled but no initial digest is explicitly known. In such cases, Renovate just silently stops updating: see. #20160.Additionally, some managers like
bazel
never pass adigest
because they handle the digest on their own. i.e. for Bazel updates with github releases, the actual artifact checksum is used as digest and needs to use an algorithm as determined by the manager.The current approach of
getDigest
(introduced with #6422) involves consulting the current digest and iterating through the releases of thecurrentValue
to figure out which artifact is used for the digest. The artifact is then mapped back to the new release (with some trickery to also ignore version names in the filename..). This is somewhat reasonable but the data source generally does not have a clear insight into what GitHub artifact(s) are used by the manager. Or, alternatively, a manager might not even want the digest of an individual artifact. e.g. as seen in: #19550Documentation (please check one with an [x])
How I've tested my work (please select one)
I have verified these changes via: