Open jmtd opened 11 months ago
Issues go stale after 90d of inactivity.
Mark the issue as fresh by commenting /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen
.
If this issue is safe to close now please do so with /close
.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh by commenting /remove-lifecycle rotten
.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen
.
If this issue is safe to close now please do so with /close
.
/lifecycle rotten /remove-lifecycle stale
/remove-lifecycle rotten
Rotten issues close after 30d of inactivity.
Reopen the issue by commenting /reopen
.
Mark the issue as fresh by commenting /remove-lifecycle rotten
.
Exclude this issue from closing again by commenting /lifecycle frozen
.
/close
@openshift-bot: Closing this issue.
/reopen
I guess the bot didn’t like my fresh command
@jmtd: Reopened this issue.
Rotten issues close after 30d of inactivity.
Reopen the issue by commenting /reopen
.
Mark the issue as fresh by commenting /remove-lifecycle rotten
.
Exclude this issue from closing again by commenting /lifecycle frozen
.
/close
@openshift-bot: Closing this issue.
/reopen /remove-lifecycle rotten /lifecycle frozen
@jmtd: Reopened this issue.
This is a little odd.
s2i build --pull-policy if-not-present
appears to query a remote registry for (at least) metadata even if the named image is present in the local registry.Log excerpt from https://github.com/jboss-container-images/openjdk/actions/runs/6864309836/job/19052020240 (the original logs are enormous):
Note that the named builder image
ubi9/openjdk-17
exists in the local docker container storage, and the rest the S2I process works as expected using the local image.Confirmed with 1.3.4 and 1.3.9.