Allow Bazel lockfile refreshes for aya-rs/aya and aya-rs/bpf-linker

[tamird]

Prepared and posted by Codex on Tamir (@tamird)'s behalf.

What would you like help with?

Please allow bazel mod deps --lockfile_mode=update as a post-upgrade command for the existing Mend-hosted installations of aya-rs/aya and aya-rs/bpf-linker. Please also enable bazelModDeps in allowedUnsafeExecutions for their native Bazel module lockfile updates, if supported for these OSS repositories.

Organisation URL

https://github.com/aya-rs

Additional information

Both repositories use rules_rs, which derives Bazel dependencies from Cargo.lock and records crate facts in MODULE.bazel.lock. We would like Cargo updates to refresh both locks in the same PR. This is the existing cross-manager limitation discussed in #42046. Dependabot also lacks this coordination; we currently rely on subsequent main-branch automation to refresh the Bazel lockfile.

The proposed Cargo package rule would use:

"postUpgradeTasks": {
  "commands": ["bazel mod deps --lockfile_mode=update"],
  "executionMode": "branch",
  "fileFilters": ["MODULE.bazel.lock"],
  "installTools": {"bazelisk": {}}
}

Could you confirm that the hosted runner supports installing Bazelisk this way and that bazel invokes the version selected by the repository's .bazelversion? Both repositories currently select Bazel 9.1.1; Aya has a pending migration selecting the immutable fork release tamird/10.0.0-702b0be17d. If the supported command must instead invoke bazelisk explicitly, please let us know which exact command can be allowlisted.

Please let us know whether these settings are supported for our current hosted plan and whether anything further is required from the repository administrators.

[jamietanna]

Hey @tamird!

Instead of explicitly allowlisting that postUpgradeTasks command, I could set allowedUnsafeExecutions=bazelModDeps so you can use the inbuilt lockfile support which would then require no extra work in your Renovate config?

[tamird]

Thanks, Jamie! Please enable allowedUnsafeExecutions=bazelModDeps for aya-rs/aya and aya-rs/bpf-linker. Thank you for the OSS upgrade, too.

One clarification on the Cargo case from #42046: will the native support also regenerate MODULE.bazel.lock after a Cargo-only update changes Cargo.lock, while MODULE.bazel and the Bazel version remain unchanged? Our rules_rs dependencies record Cargo-derived facts in the Bazel lockfile. The documentation describes regeneration after Bazel module updates, so we want to confirm that distinction.

Our existing main-branch lock-refresh automation will continue meanwhile.

Prepared and posted by Codex on @tamird’s behalf.

[jamietanna]

I would say no, it won't (based on that Discussion) - not sure if it's worth seeing if that can be fixed first? (We'd welcome a PR)

[jamietanna]

I'll also give you an upgrade to #33617 (as you qualify) 🚀

This gives you:

• 2 concurrent jobs per organisation (i.e. 2 of your 15 repos on the org will process concurrently)
• double memory (6GB)
• access to Merge Confidence Workflows - you'll be able to use matchConfidence to group PRs based on the Merge Confidence

Please give us a shout if you have any feedback, in particular on Merge Confidence Workflows!