GitHub releases datasource prevents updates when pinning is enabled #20160
Labels
status:requirements
Full requirements are not yet known, so implementation should not be started
type:bug
Bug fix of existing functionality
Comments
devversion
added
priority-5-triage
status:requirements
|
It seems like the current I would be happy to help improve this. I was already investigating/experimenting a lot, but don't know what solution the team prefers here. A release can contain X artifacts, and only via a specific artifact URL, a single artifact could be used for the digest computation |
|
you're probably hit by |
|
Thanks @viceice - yeah seems very related. Using the underlying commit of a tag as digest seems reasonable to me. I don't know if we can preserve the current behavior in |
devversion
added a commit
to devversion/renovate
that referenced
this issue
Feb 2, 2023
This fixes the issue where updates are silently omitted due to the new digest not being computable. Improving the situation as in: renovatebot#20160.
devversion
added a commit
to devversion/renovate
that referenced
this issue
Feb 2, 2023
… underlying Git tag Currently the `github-releases` datasource `getDigest` 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. renovatebot#20160. Additionally, some managers like `bazel` never pass a `digest` 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` involves consulting the current digest and iterating through the releases of the `currentValue` 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: renovatebot#19550 A more concrete and predictable digest of a GitHub release is the underlying SHA of the release. This prevents cases where the release tag is changed to another version. The individual managers are responsible for deciding whether the SHA is relevant or not, or if they want to use an individual artifact. The managers known the best since they have access to the URL. like seen in `bazel`. The problem that was solved with the current `getDigest` implementation can be solved long-term with: https://github.com/renovatebot/renovate/issues/6422. BREAKING CHANGE: Regex Manager configurations relying on the `github-release` data-source with digests will have different digest semantics. The digest will always correspond to the underlying Git SHA of the release/version. Fixes renovatebot#20160.
devversion
added a commit
to devversion/renovate
that referenced
this issue
Feb 2, 2023
… underlying Git tag Currently the `github-releases` datasource `getDigest` 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. renovatebot#20160. Additionally, some managers like `bazel` never pass a `digest` 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` involves consulting the current digest and iterating through the releases of the `currentValue` 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: renovatebot#19550 A more concrete and predictable digest of a GitHub release is the underlying SHA of the release. This prevents cases where the release tag is changed to another version. The individual managers are responsible for deciding whether the SHA is relevant or not, or if they want to use an individual artifact. The managers known the best since they have access to the URL. like seen in `bazel`. The problem that was solved with the current `getDigest` implementation can be solved long-term with: https://github.com/renovatebot/renovate/issues/6422. BREAKING CHANGE: Regex Manager configurations relying on the `github-release` data-source with digests will have different digest semantics. The digest will always correspond to the underlying Git SHA of the release/version. Fixes renovatebot#20160.
6 tasks
devversion
added a commit
to devversion/renovate
that referenced
this issue
Feb 2, 2023
This fixes the issue where updates are silently omitted due to the new digest not being computable. Improving the situation as in: renovatebot#20160.
devversion
added a commit
to devversion/renovate
that referenced
this issue
Feb 2, 2023
… underlying Git tag Currently the `github-releases` datasource `getDigest` 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. renovatebot#20160. Additionally, some managers like `bazel` never pass a `digest` 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` involves consulting the current digest and iterating through the releases of the `currentValue` 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: renovatebot#19550 A more concrete and predictable digest of a GitHub release is the underlying SHA of the release. This prevents cases where the release tag is changed to another version. The individual managers are responsible for deciding whether the SHA is relevant or not, or if they want to use an individual artifact. The managers known the best since they have access to the URL. like seen in `bazel`. The problem that was solved with the current `getDigest` implementation can be solved long-term with: https://github.com/renovatebot/renovate/issues/6422. BREAKING CHANGE: Regex Manager configurations relying on the `github-release` data-source with digests will have different digest semantics. The digest will always correspond to the underlying Git SHA of the release/version. Fixes renovatebot#20160.
|
I've created a draft proposal PR to replace this digest logic: #20178. I've done it as a breaking change because that feels like the best to me (a draft to discuss this further) |
devversion
added a commit
to devversion/renovate
that referenced
this issue
Feb 3, 2023
This fixes the issue where updates are silently omitted due to the new digest not being computable. Improving the situation as in: renovatebot#20160.
devversion
added a commit
to devversion/renovate
that referenced
this issue
Feb 9, 2023
…t` logic In the previous commit, the `github-releases` datasource has been renamed to `github-release-attachments`. The `github-releases` datasource `getDigest` method was rather magical and depended/required 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 stoped updating: see. renovatebot#20160. Additionally, some managers like `bazel` never pass a `digest` 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` involved consulting the current digest and iterating through the releases of the `currentValue` to figure out which artifact/attachcment 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: renovatebot#19550 To solve this, the existing datasource with this attachment logic is was moved into `github-release-attachments`, while the more general `github-releases` datasource is updated to use the underlying Git tag for digest computation of a release entry. BREAKING CHANGE: Regex Manager configurations relying on the `github-release` data-source with digests will have different digest semantics. The digest will always correspond to the underlying Git SHA of the release/version now. The old behavior can be preserved by switching to the `github-release-attachments` datasource. Fixes renovatebot#20160. Fixes renovatebot#19552.
devversion
added a commit
to devversion/renovate
that referenced
this issue
Feb 9, 2023
…t` logic In the previous commit, the `github-releases` datasource has been renamed to `github-release-attachments`. The `github-releases` datasource `getDigest` method was rather magical and depended/required 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 stoped updating: see. renovatebot#20160. Additionally, some managers like `bazel` never pass a `digest` 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` involved consulting the current digest and iterating through the releases of the `currentValue` to figure out which artifact/attachcment 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: renovatebot#19550 To solve this, the existing datasource with this attachment logic is was moved into `github-release-attachments`, while the more general `github-releases` datasource is updated to use the underlying Git tag for digest computation of a release entry. BREAKING CHANGE: Regex Manager configurations relying on the `github-release` data-source with digests will have different digest semantics. The digest will always correspond to the underlying Git SHA of the release/version now. The old behavior can be preserved by switching to the `github-release-attachments` datasource. Fixes renovatebot#20160. Fixes renovatebot#19552.
devversion
added a commit
to devversion/renovate
that referenced
this issue
Feb 9, 2023
…t` logic In the previous commit, the `github-releases` datasource has been renamed to `github-release-attachments`. The `github-releases` datasource `getDigest` method was rather magical and depended/required 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 stoped updating: see. renovatebot#20160. Additionally, some managers like `bazel` never pass a `digest` 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` involved consulting the current digest and iterating through the releases of the `currentValue` to figure out which artifact/attachcment 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: renovatebot#19550 To solve this, the existing datasource with this attachment logic is was moved into `github-release-attachments`, while the more general `github-releases` datasource is updated to use the underlying Git tag for digest computation of a release entry. BREAKING CHANGE: Regex Manager configurations relying on the `github-release` data-source with digests will have different digest semantics. The digest will always correspond to the underlying Git SHA of the release/version now. The old behavior can be preserved by switching to the `github-release-attachments` datasource. Fixes renovatebot#20160. Fixes renovatebot#19552.
devversion
added a commit
to devversion/renovate
that referenced
this issue
Feb 20, 2023
…t` logic In the previous commit, the `github-releases` datasource has been renamed to `github-release-attachments`. The `github-releases` datasource `getDigest` method was rather magical and depended/required 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 stoped updating: see. renovatebot#20160. Additionally, some managers like `bazel` never pass a `digest` 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` involved consulting the current digest and iterating through the releases of the `currentValue` to figure out which artifact/attachcment 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: renovatebot#19550 To solve this, the existing datasource with this attachment logic is was moved into `github-release-attachments`, while the more general `github-releases` datasource is updated to use the underlying Git tag for digest computation of a release entry. BREAKING CHANGE: Regex Manager configurations relying on the `github-release` data-source with digests will have different digest semantics. The digest will always correspond to the underlying Git SHA of the release/version now. The old behavior can be preserved by switching to the `github-release-attachments` datasource. Fixes renovatebot#20160. Fixes renovatebot#19552.
rarkins
pushed a commit
that referenced
this issue
Mar 10, 2023
…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.
rarkins
pushed a commit
that referenced
this issue
Mar 10, 2023
…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.
|
🎉 This issue has been resolved in version 35.0.0 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
How are you running Renovate?
Self-hosted
If you're self-hosting Renovate, tell us what version of Renovate you run.
34.95.0
If you're self-hosting Renovate, select which platform you are using.
github.com
If you're self-hosting Renovate, tell us what version of the platform you run.
github.com
Was this something which used to work for you, and then stopped?
It used to work, and then stopped
Describe the bug
A very long time ago in Angular repositories we noticed that some Bazel
WORKSPACEhttp_archivedependencies are no longer updated. Some rules were updated, some not.Today I investigated & debugged this and it turned out to be only for
http_archiverules using GitHub release URLs. The GitHub releases datasource seems properly determine the latest version, but thelookup/index.tsfile discards the update because the github-releases datasource is not able to compute agetDigest() = null, causing the update to be skipped as per: https://github.com/renovatebot/renovate/blob/main/lib/workers/repository/process/lookup/index.ts#L404There is no log warning etc. the rule is just never updated silently.
The
getDigestmethod was implemented for the releases data source with: 91e2743.Issue can be reproduced with
build_bazel_rules_nodejsinWORKSPACEin https://github.com/angular/angularRelevant debug logs
No response
Have you created a minimal reproduction repository?
No reproduction, but I have linked to a public repo where it occurs
The text was updated successfully, but these errors were encountered: