cachekit-core 0.7.3

LZ4 compression, xxHash3 integrity, AES-256-GCM encryption for byte payloads
Documentation
{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["local>cachekit-io/renovate-config"],
  "packageRules": [
    {
      "description": "Hold getrandom at 0.2. The direct 0.2 entry turns on the js feature for the getrandom 0.2 copy that ring and rand_core also use on wasm32, and getrandom 0.3 removed that feature, so a bump past 0.2 fails the Cargo.lock update. It waits under Pending Approval on the Dependency Dashboard instead of opening a PR that cannot pass. Vulnerability updates are not held: Renovate forces dependencyDashboardApproval off for them. Drop this rule once nothing in Cargo.lock depends on getrandom 0.2.",
      "matchManagers": ["cargo"],
      "matchPackageNames": ["getrandom"],
      "matchUpdateTypes": ["minor", "major"],
      "groupName": null,
      "dependencyDashboardApproval": true
    },
    {
      "description": "Hold generic-array at 0.14.7. crypto-common 0.1, which the RustCrypto 0.10 crates depend on, pins generic-array to exactly 0.14.7, so any other 0.14.x fails the Cargo.lock update and takes the whole non-major group with it. It waits under Pending Approval on the Dependency Dashboard instead. Vulnerability updates are not held. Drop this rule once nothing in Cargo.lock depends on crypto-common 0.1.",
      "matchManagers": ["cargo"],
      "matchPackageNames": ["generic-array"],
      "matchUpdateTypes": ["patch"],
      "groupName": null,
      "dependencyDashboardApproval": true
    },
    {
      "description": "Hold wasm-bindgen-test. It is exact-pinned and pins wasm-bindgen exactly in turn, and the wasm32 CI job's wasm-bindgen-test-runner (WASM_BINDGEN_VERSION and WASM_BINDGEN_SHA256 in ci.yml) must match the locked wasm-bindgen, so the pin, Cargo.lock and the runner move together by hand. A Renovate update moves the pin and Cargo.lock but not the runner, so that job's version check fails, and it waits under Pending Approval on the Dependency Dashboard instead. Vulnerability updates are not held.",
      "matchManagers": ["cargo"],
      "matchPackageNames": ["wasm-bindgen-test"],
      "groupName": null,
      "dependencyDashboardApproval": true
    },
    {
      "description": "Hold proptest and xxhash-rust. No audit source that supply-chain/ imports covers them, and audits.toml does not trust their publishers, so each new version fails cargo vet until someone records an exemption or audit for that version. proptest 1.12.0 also brings in crates that supply-chain/ does not cover yet. Without this rule the version would fail its whole group: rust-dev-deps for proptest, non-major for xxhash-rust. It waits under Pending Approval on the Dependency Dashboard instead, and whoever approves it adds the supply-chain entries on that branch. Vulnerability updates are not held. Drop a crate from this rule if either of those changes for it.",
      "matchManagers": ["cargo"],
      "matchPackageNames": ["proptest", "xxhash-rust"],
      "groupName": null,
      "dependencyDashboardApproval": true
    },
    {
      "description": "Cargo dev-dependency updates never automerge in this repo. This overrides the shared preset, which automerges them through its rust-dev-deps group and its dev-dependency rule. Crates whose publisher is trusted in supply-chain/audits.toml pass cargo vet with no per-version review, and any dev-dependency update can move a runtime dependency in the shared Cargo.lock. So the rule matches every dev-dependency, not only the trusted crates, and a human merges each one. Keep this rule last in this file: a later rule here that sets automerge would override it.",
      "matchManagers": ["cargo"],
      "matchDepTypes": ["dev-dependencies"],
      "automerge": false
    }
  ]
}