chore(deps): update gcr.io/kaniko-project/executor docker tag to v1.24.0

[renovate]

This PR contains the following updates:

Package	Type	Update	Change
gcr.io/kaniko-project/executor	final	minor	v1.23.2-debug → v1.24.0-debug

---

Release Notes

GoogleContainerTools/kaniko (gcr.io/kaniko-project/executor)

v1.24.0

Compare Source

The executor images in this release are:

gcr.io/kaniko-project/executor:v1.24.0
gcr.io/kaniko-project/executor:latest

The debug images are available at:

gcr.io/kaniko-project/executor:debug
gcr.io/kaniko-project/executor:v1.24.0-debug

The slim executor images which don't contain any authentication binaries are available at:

gcr.io/kaniko-project/executor:slim
gcr.io/kaniko-project/executor:v1.24.0-slim

Huge thank you for this release towards our contributors:

• Aaron Prindle
• Aswin A
• dependabot[bot]
• Michael Plump
• Mick van Gelderen
• Thomas L. Kjeldsen

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), 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 was generated by Mend Renovate. View the repository job log.

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to 333b379 in 20 seconds. Click for details.

• Reviewed 13 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 1 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. Dockerfile:5

• Draft comment:
  Ensure v1.24.0-debug is fully backward compatible. Consider pinning to a digest for immutability.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% The comment is asking the PR author to ensure backward compatibility and consider pinning to a digest for immutability. This falls under the rule of not asking the author to ensure behavior or compatibility, which is not allowed.

Workflow ID: wflow_hZlfKhywjSNKQrDT

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to 6f6d581 in 27 seconds. Click for details.

• Reviewed 13 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 1 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. Dockerfile:5

• Draft comment:
  Updated base image to v1.24.0-debug. Ensure no breaking changes in the new release affect your build.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

Workflow ID: wflow_6cQwpkyyyK6uGS9A

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to fb5fdf2 in 1 minute and 9 seconds. Click for details.

• Reviewed 13 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 1 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. Dockerfile:5

• Draft comment:
  Updated image to v1.24.0-debug; consider using an immutable digest to ensure reproducible builds.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 30% vs. threshold = 50% The comment acknowledges the change (version update) and then suggests a best practice (using digest instead of tag). However, this falls into a gray area: it's suggesting a code quality improvement, but it's not directly addressing an issue with the change itself. The PR author intentionally updated to v1.24.0-debug, and the comment is suggesting they should have used a different approach entirely (digest vs tag). This is more of a general best practice suggestion rather than feedback on what was actually changed. The rules state that comments should be actionable and clear code quality refactors are good, but also that we shouldn't make comments unless there's clearly a code change required. Using tags vs digests is a valid approach, just with different tradeoffs. This could be considered an actionable code quality suggestion since using digests is objectively more reproducible than tags. The comment is clear about what to do. It's not speculative or asking for confirmation - it's making a concrete suggestion. While using digests is a best practice, the current approach using version tags is not incorrect or broken. The comment is more of a "nice to have" suggestion rather than identifying a problem with the change. The rules emphasize not commenting unless there's clearly a code change required, and this seems more advisory than necessary. This comment should be deleted. While it suggests a valid best practice, it's not identifying a problem with the actual change made. The version update itself is fine, and suggesting a different approach (digest vs tag) is advisory rather than addressing a clear issue that requires a code change.

Workflow ID: wflow_2xia4SsTQga3ZaIA

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}