repository_ctx.download* does not use URL as default canonical ID

[Silic0nS0ldier]

Description of the bug:

Prior to Bazel v7, .download and .download_and_extract were beholden to the flag --repository_cache_urls_as_default_canonical_id which in Bazel v6 (and possibly earlier) was enabled by default.

As of #20047 this logic was lifted out of src/main/java/com/google/devtools/build/lib/bazel/repository/downloader/DownloadManager.java, making it specific to the following repository rules/macros (via tools/build_defs/repo/cache.bzl).

• http_archive
• http_file
• http_jar
• jvm_maven_import_external
• jvm_import_external

Bazel v7 release notes do not mention that repository_ctx.download and repository_ctx.download_and_extract no longer use URLs as the default canonical ID.

Which category does this issue belong to?

Configurability, External Dependency, Rules API

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

1. Create a simple repository_rule which downloads a file, passing in a value for integrity.
2. Run it.
3. Modify the URL to anything else (file does not need to exist).
4. Run it again, observe no failure (pulled from cache using integrity).

Which operating system are you running Bazel on?

macOS, Ubuntu (Linux)

What is the output of bazel info release?

release 7.1.2

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse HEAD ?

No response

Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.

The release notes do not explicitly mention this behaviour change, so I believe this is an unintended regression.

Commit: a6f8923

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

No response

[fmeum]

Prior to Bazel v7, .download and .download_and_extract were beholden to the flag --experimental_repository_cache_urls_as_default_canonical_id...

This is correct. As of Bazel 7, the flag is now a no-op and the repo rules you listed have been updated to use this logic by default.

... which in Bazel v6 (and possibly earlier) was enabled by default.

This is not correct, the flag wasn't enabled by default in previous versions of Bazel:
https://cs.opensource.google/bazel/bazel/+/release-6.5.0:src/main/java/com/google/devtools/build/lib/bazel/repository/RepositoryOptions.java;l=243

If you are using rctx.download or rctx.download_and_extract in a custom repo rule and were previously using the --experimental_repository_cache_urls_as_default_canonical_id flag to set a default canonical ID, you would have to update the logic to manually pass URLs into the canonical ID field. You can use the new public helper function get_default_canonical_id in @bazel_tools//tools/build_defs/repo:cache.bzl if you want to match the behavior of the special-cased rules.

[Silic0nS0ldier]

Ah, my mistake. Perhaps the flag had been in use in our repo, or perhaps I had simply made a bad assumption.

In this case I have some suggestions;

• rctx.download* documentation should be updated to include what the default canonical_id is.
• rctx.download* documentation should include examples for common patterns (such as using get_default_canonical_id).
• Co-ordinate with ruleset authors so API usage uses an appropriate canonical_id (not having it set is probably a good signal that the behaviour hasn't been considered).

Some extra context for my request which I neglected to include in the OP. Due to the default behaviour, a TypeScript version upgrade was merged in a broken state due to an overlooked integrity hash.

load("@aspect_rules_ts//ts:repositories.bzl", "rules_ts_dependencies")
rules_ts_dependencies(
    ts_version_from = "//:package.json", # 5.4.2 -> 5.4.5
-   ts_integrity = "sha512-+2/g0Fds1ERlP6JsakQQDXjZdZMM+rqpamFZJEKh4kwTIn3iDkgKtby0CeNd5ATNZ4Ry1ax15TMx0W2V+miizQ==",
+   ts_integrity = "sha512-vcI4UpRgg81oIRUFwR0WSIHKt11nJ7SAVlYNIu+QpqeyXP+gpQJy/Z4+F0aGxSE4MqwjyXvW/TzgkLAx2AGHwQ==",
)

This specific instance of the issue should not reoccur as we've updated usage to automatically pick up the hash.

rules_ts_dependencies(
    ts_version_from = "@pnpm//:typescript/resolved.json",
)

[Silic0nS0ldier]

I looked into using @bazel_tools//tools/build_defs/repo:cache.bzl in an internal repo rule, without success. The helper has visibility("private") preventing usage, it is not currently part of the public API.

[fmeum]

Feel free to send a PR to remove that restriction!

[Silic0nS0ldier]

Doc change and helper are merged. All that remains is making sure rulesets match user expectations. Not enough reason to keep this open IMO, so closing.