chore(deps): update registry.access.redhat.com/ubi8/openjdk-17 docker tag to v1.20-2.1731461738 - autoclosed

[redhat-renovate-bot]

This PR contains the following updates:

Package	Update	Change
registry.access.redhat.com/ubi8/openjdk-17	patch	1.20-2.1721231681 -> 1.20-2.1731461738

---

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

---

Configuration

📅 Schedule: Branch creation - "on the 2nd and 4th day instance on thursday after 9pm" in timezone America/Toronto, 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.

[RomanNikitenko]

I tested simple actions, like:

• open a file
• create a terminal
• run a command
• install an extension

I didn't detect any problem with the new image tag.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: redhat-renovate-bot, RomanNikitenko
Once this PR has been reviewed and has the lgtm label, please assign elsony for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[thepetk]

Needs review from @maxandersen as the stack owner.

/retest

[openshift-ci]

New changes are detected. LGTM label has been removed.

[maxandersen]

fyi - you really should not wait on me reviewing a patch update to the JDK image.

[thepetk]

fyi - you really should not wait on me reviewing a patch update to the JDK image.

To clarify, that is the process as mentioned in the Lifecycle and Contributing documents. Therefore, the stack owner is responsible for stack maintainance and whenever a PR is opened for the stack it needs two approvals (one from the stack owner and one from the che team).