Update gradle/actions digest to 9c97196 (branch_9x)

[solrbot]

This PR contains the following updates:

Package	Type	Update	Change
gradle/actions	action	digest	67621b1 → 9c97196

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • "before 9am on the first day of the month"
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Renovate Bot

[epugh]

Did the version stay the same if the digest changed? Do we really need the version? Stupid digest use!!!

[epugh]

I was a bit weirded out about this, but apparently we are just moving from one sha to a better sha...

Claude says:

The "old" SHA (67621b124...) was never a commit — it was the SHA of the annotated tag objectv6.3.0 itself (Git distinguishes lightweight tags from annotated tag objects; this one is signed and GitHub verifies it: "tagger":"Daz DeBoer <daz@gradle.com>", "verified":true). Dereferencing that tag object shows:

"tag": "v6.3.0",
"object": { "sha": "9c971963bec38e04b3d30dcc455b5382be2fdbfb", "type": "commit" }

The "new" SHA (9c971963...) is exactly the commit that tag object points to. So this PR doesn't change what code you're running at all — it's the samev6.3.0 release, same commit, same content. The only thing changing is which of two valid-but-different object IDs Solr's workflow pins by: the tag-object SHA (indirect, one hop through the tag) vs. the commit SHA it dereferences to (direct). GitHub Actions can check out either one and gets identical content either way.

So: the version didn't change, and neither did the actual code — Renovate is just normalizing the pin from "tag object SHA" to "the commit SHA that tag object verifiably points to." That's a real Renovate feature (digest pinning also tracks/dereferences annotated tag objects), and it's the good kind of SHA update, not a tag-hijack red flag — worth noting since digest pinning exists specifically to catch the malicious version of this (a tag silently repointed to different content), and here the signature verification confirms that didn't happen.

[solrbot]

This PR contains the following updates:

Package	Type	Update	Change
gradle/actions	action	digest	67621b1 → 9c97196

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • "before 9am on the first day of the month"
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Renovate Bot

[epugh]

Did the version stay the same if the digest changed? Do we really need the version? Stupid digest use!!!

[epugh]

I was a bit weirded out about this, but apparently we are just moving from one sha to a better sha...

Claude says:

The "old" SHA (67621b124...) was never a commit — it was the SHA of the annotated tag objectv6.3.0 itself (Git distinguishes lightweight tags from annotated tag objects; this one is signed and GitHub verifies it: "tagger":"Daz DeBoer <daz@gradle.com>", "verified":true). Dereferencing that tag object shows:

"tag": "v6.3.0",
"object": { "sha": "9c971963bec38e04b3d30dcc455b5382be2fdbfb", "type": "commit" }

The "new" SHA (9c971963...) is exactly the commit that tag object points to. So this PR doesn't change what code you're running at all — it's the samev6.3.0 release, same commit, same content. The only thing changing is which of two valid-but-different object IDs Solr's workflow pins by: the tag-object SHA (indirect, one hop through the tag) vs. the commit SHA it dereferences to (direct). GitHub Actions can check out either one and gets identical content either way.

So: the version didn't change, and neither did the actual code — Renovate is just normalizing the pin from "tag object SHA" to "the commit SHA that tag object verifiably points to." That's a real Renovate feature (digest pinning also tracks/dereferences annotated tag objects), and it's the good kind of SHA update, not a tag-hijack red flag — worth noting since digest pinning exists specifically to catch the malicious version of this (a tag silently repointed to different content), and here the signature verification confirms that didn't happen.

[solrbot]

This PR contains the following updates:

Package	Type	Update	Change
gradle/actions	action	digest	67621b1 → 9c97196

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • "before 9am on the first day of the month"
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Renovate Bot

[epugh]

Did the version stay the same if the digest changed? Do we really need the version? Stupid digest use!!!

[epugh]

I was a bit weirded out about this, but apparently we are just moving from one sha to a better sha...

Claude says:

The "old" SHA (67621b124...) was never a commit — it was the SHA of the annotated tag objectv6.3.0 itself (Git distinguishes lightweight tags from annotated tag objects; this one is signed and GitHub verifies it: "tagger":"Daz DeBoer <daz@gradle.com>", "verified":true). Dereferencing that tag object shows:

"tag": "v6.3.0",
"object": { "sha": "9c971963bec38e04b3d30dcc455b5382be2fdbfb", "type": "commit" }

The "new" SHA (9c971963...) is exactly the commit that tag object points to. So this PR doesn't change what code you're running at all — it's the samev6.3.0 release, same commit, same content. The only thing changing is which of two valid-but-different object IDs Solr's workflow pins by: the tag-object SHA (indirect, one hop through the tag) vs. the commit SHA it dereferences to (direct). GitHub Actions can check out either one and gets identical content either way.

So: the version didn't change, and neither did the actual code — Renovate is just normalizing the pin from "tag object SHA" to "the commit SHA that tag object verifiably points to." That's a real Renovate feature (digest pinning also tracks/dereferences annotated tag objects), and it's the good kind of SHA update, not a tag-hijack red flag — worth noting since digest pinning exists specifically to catch the malicious version of this (a tag silently repointed to different content), and here the signature verification confirms that didn't happen.

[solrbot]

This PR contains the following updates:

Package	Type	Update	Change
gradle/actions	action	digest	67621b1 → 9c97196

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • "before 9am on the first day of the month"
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Renovate Bot

[epugh]

Did the version stay the same if the digest changed? Do we really need the version? Stupid digest use!!!

[epugh]

I was a bit weirded out about this, but apparently we are just moving from one sha to a better sha...

Claude says:

The "old" SHA (67621b124...) was never a commit — it was the SHA of the annotated tag objectv6.3.0 itself (Git distinguishes lightweight tags from annotated tag objects; this one is signed and GitHub verifies it: "tagger":"Daz DeBoer <daz@gradle.com>", "verified":true). Dereferencing that tag object shows:

"tag": "v6.3.0",
"object": { "sha": "9c971963bec38e04b3d30dcc455b5382be2fdbfb", "type": "commit" }

The "new" SHA (9c971963...) is exactly the commit that tag object points to. So this PR doesn't change what code you're running at all — it's the samev6.3.0 release, same commit, same content. The only thing changing is which of two valid-but-different object IDs Solr's workflow pins by: the tag-object SHA (indirect, one hop through the tag) vs. the commit SHA it dereferences to (direct). GitHub Actions can check out either one and gets identical content either way.

So: the version didn't change, and neither did the actual code — Renovate is just normalizing the pin from "tag object SHA" to "the commit SHA that tag object verifiably points to." That's a real Renovate feature (digest pinning also tracks/dereferences annotated tag objects), and it's the good kind of SHA update, not a tag-hijack red flag — worth noting since digest pinning exists specifically to catch the malicious version of this (a tag silently repointed to different content), and here the signature verification confirms that didn't happen.

[solrbot]

This PR contains the following updates:

Package	Type	Update	Change
gradle/actions	action	digest	67621b1 → 9c97196

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • "before 9am on the first day of the month"
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Renovate Bot

[epugh]

Did the version stay the same if the digest changed? Do we really need the version? Stupid digest use!!!

[epugh]

I was a bit weirded out about this, but apparently we are just moving from one sha to a better sha...

Claude says:

The "old" SHA (67621b124...) was never a commit — it was the SHA of the annotated tag objectv6.3.0 itself (Git distinguishes lightweight tags from annotated tag objects; this one is signed and GitHub verifies it: "tagger":"Daz DeBoer <daz@gradle.com>", "verified":true). Dereferencing that tag object shows:

"tag": "v6.3.0",
"object": { "sha": "9c971963bec38e04b3d30dcc455b5382be2fdbfb", "type": "commit" }

The "new" SHA (9c971963...) is exactly the commit that tag object points to. So this PR doesn't change what code you're running at all — it's the samev6.3.0 release, same commit, same content. The only thing changing is which of two valid-but-different object IDs Solr's workflow pins by: the tag-object SHA (indirect, one hop through the tag) vs. the commit SHA it dereferences to (direct). GitHub Actions can check out either one and gets identical content either way.

So: the version didn't change, and neither did the actual code — Renovate is just normalizing the pin from "tag object SHA" to "the commit SHA that tag object verifiably points to." That's a real Renovate feature (digest pinning also tracks/dereferences annotated tag objects), and it's the good kind of SHA update, not a tag-hijack red flag — worth noting since digest pinning exists specifically to catch the malicious version of this (a tag silently repointed to different content), and here the signature verification confirms that didn't happen.

[solrbot]

This PR contains the following updates:

Package	Type	Update	Change
gradle/actions	action	digest	67621b1 → 9c97196

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • "before 9am on the first day of the month"
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Renovate Bot

[epugh]

Did the version stay the same if the digest changed? Do we really need the version? Stupid digest use!!!

[epugh]

I was a bit weirded out about this, but apparently we are just moving from one sha to a better sha...

Claude says:

The "old" SHA (67621b124...) was never a commit — it was the SHA of the annotated tag objectv6.3.0 itself (Git distinguishes lightweight tags from annotated tag objects; this one is signed and GitHub verifies it: "tagger":"Daz DeBoer <daz@gradle.com>", "verified":true). Dereferencing that tag object shows:

"tag": "v6.3.0",
"object": { "sha": "9c971963bec38e04b3d30dcc455b5382be2fdbfb", "type": "commit" }

The "new" SHA (9c971963...) is exactly the commit that tag object points to. So this PR doesn't change what code you're running at all — it's the samev6.3.0 release, same commit, same content. The only thing changing is which of two valid-but-different object IDs Solr's workflow pins by: the tag-object SHA (indirect, one hop through the tag) vs. the commit SHA it dereferences to (direct). GitHub Actions can check out either one and gets identical content either way.

So: the version didn't change, and neither did the actual code — Renovate is just normalizing the pin from "tag object SHA" to "the commit SHA that tag object verifiably points to." That's a real Renovate feature (digest pinning also tracks/dereferences annotated tag objects), and it's the good kind of SHA update, not a tag-hijack red flag — worth noting since digest pinning exists specifically to catch the malicious version of this (a tag silently repointed to different content), and here the signature verification confirms that didn't happen.

[solrbot]

This PR contains the following updates:

Package	Type	Update	Change
gradle/actions	action	digest	67621b1 → 9c97196

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • "before 9am on the first day of the month"
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Renovate Bot

[epugh]

Did the version stay the same if the digest changed? Do we really need the version? Stupid digest use!!!

[epugh]

I was a bit weirded out about this, but apparently we are just moving from one sha to a better sha...

Claude says:

The "old" SHA (67621b124...) was never a commit — it was the SHA of the annotated tag objectv6.3.0 itself (Git distinguishes lightweight tags from annotated tag objects; this one is signed and GitHub verifies it: "tagger":"Daz DeBoer <daz@gradle.com>", "verified":true). Dereferencing that tag object shows:

"tag": "v6.3.0",
"object": { "sha": "9c971963bec38e04b3d30dcc455b5382be2fdbfb", "type": "commit" }

The "new" SHA (9c971963...) is exactly the commit that tag object points to. So this PR doesn't change what code you're running at all — it's the samev6.3.0 release, same commit, same content. The only thing changing is which of two valid-but-different object IDs Solr's workflow pins by: the tag-object SHA (indirect, one hop through the tag) vs. the commit SHA it dereferences to (direct). GitHub Actions can check out either one and gets identical content either way.

So: the version didn't change, and neither did the actual code — Renovate is just normalizing the pin from "tag object SHA" to "the commit SHA that tag object verifiably points to." That's a real Renovate feature (digest pinning also tracks/dereferences annotated tag objects), and it's the good kind of SHA update, not a tag-hijack red flag — worth noting since digest pinning exists specifically to catch the malicious version of this (a tag silently repointed to different content), and here the signature verification confirms that didn't happen.

[solrbot]

This PR contains the following updates:

Package	Type	Update	Change
gradle/actions	action	digest	67621b1 → 9c97196

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • "before 9am on the first day of the month"
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Renovate Bot

[epugh]

Did the version stay the same if the digest changed? Do we really need the version? Stupid digest use!!!

[epugh]

I was a bit weirded out about this, but apparently we are just moving from one sha to a better sha...

Claude says:

The "old" SHA (67621b124...) was never a commit — it was the SHA of the annotated tag objectv6.3.0 itself (Git distinguishes lightweight tags from annotated tag objects; this one is signed and GitHub verifies it: "tagger":"Daz DeBoer <daz@gradle.com>", "verified":true). Dereferencing that tag object shows:

"tag": "v6.3.0",
"object": { "sha": "9c971963bec38e04b3d30dcc455b5382be2fdbfb", "type": "commit" }

The "new" SHA (9c971963...) is exactly the commit that tag object points to. So this PR doesn't change what code you're running at all — it's the samev6.3.0 release, same commit, same content. The only thing changing is which of two valid-but-different object IDs Solr's workflow pins by: the tag-object SHA (indirect, one hop through the tag) vs. the commit SHA it dereferences to (direct). GitHub Actions can check out either one and gets identical content either way.

So: the version didn't change, and neither did the actual code — Renovate is just normalizing the pin from "tag object SHA" to "the commit SHA that tag object verifiably points to." That's a real Renovate feature (digest pinning also tracks/dereferences annotated tag objects), and it's the good kind of SHA update, not a tag-hijack red flag — worth noting since digest pinning exists specifically to catch the malicious version of this (a tag silently repointed to different content), and here the signature verification confirms that didn't happen.