cirrus: update CI images

[Luap99]

Images from containers/automation_images#387

Does this PR introduce a user-facing change?

None

[baude]

LGTM

[Luap99]

unknown time zone EST

unknown time zone MST7MDT

Something is broken on debian, it seems it is missing certain timezones now?

[Luap99]

unknown time zone EST

unknown time zone MST7MDT

Something is broken on debian, it seems it is missing certain timezones now?

From the debian changelog:

• Upstream obsoleted the System V names CET, CST6CDT, EET, EST*, HST, MET,
  MST*, PST8PDT, and WET. They are symlinks now. Move those zones to
  tzdata-legacy and update /etc/localtime on package update to the new names.
  Please use Etc/GMT* in case you want to avoid DST changes.

I guess I update the test here then and hope this is enough as this might hit fedora sooner or later too.

[Luap99]

@edsantiago PTAL

[edsantiago]

"Adding fedoraproject.org to the local registry cache is too hard right now," he said. "We can worry about it some other day."

Sigh.

[Luap99]

"Adding fedoraproject.org to the local registry cache is too hard right now," he said. "We can worry about it some other day."

Sigh.

[+0557s] ok 264 [700] podman play --build --context-dir in 1845ms
...
[+0681s] # # test yaml:
[+0681s] #     apiVersion: v1
[+0681s] #     kind: Pod
[+0681s] #     metadata:
[+0681s] #       labels:
[+0681s] #         app: test
[+0681s] #       name: p-t265-jok99zot
[+0681s] #     spec:
[+0681s] #       containers:
[+0681s] #       - command:
[+0681s] #         - id
[+0681s] #         image: userimage-t265-jok99zot
[+0681s] #         name: c-t265-jok99zot
[+0681s] #         resources: {}
[+0681s] #     status: {}
[+0681s] #
[+0681s] # [16:27:56.449275187] # /var/tmp/go/src/github.com/containers/podman/bin/podman play kube --build --start=false /tmp/CI_1QV2/podman_bats.36TZHH/test.yaml
[+0681s] # [16:29:56.466603131] Resolving "userimage-t265-jok99zot" using unqualified-search registries (/etc/containers/registries.conf)
[+0681s] # Trying to pull docker.io/library/userimage-t265-jok99zot:latest...
[+0681s] # Trying to pull quay.io/userimage-t265-jok99zot:latest...
[+0681s] # Trying to pull registry.fedoraproject.org/userimage-t265-jok99zot:latest...
[+0681s] # time="2024-10-10T16:28:56Z" level=warning msg="Failed, retrying in 1s ... (1/3). Error: initializing source docker://registry.fedoraproject.org/userimage-t265-jok99zot:latest: pinging container registry registry.fedoraproject.org: Get \"https://registry.fedoraproject.org/v2/\": dial tcp 38.145.60.21:443: i/o timeout"
[+0681s] # timeout: sending signal TERM to command ‘/var/tmp/go/src/github.com/containers/podman/bin/podman’
[+0681s] # [16:29:56.471535522] [ rc=124 (** EXPECTED 125 **) ]

This seems unexpected, we should not resolve the short name there I think as this is a a custom image build there.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: edsantiago, Luap99

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [Luap99,edsantiago]

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

[mheon]

/lgtm

[edsantiago]

This seems unexpected, we should not resolve the short name there I think as this is a a custom image build there.

I think shortname resolution is expected in this test:

    _write_test_yaml command=id image=$userimage    <<< if we didn't want shortname resolution, this would be qualified
    run_podman 125 play kube --build --start=false $TESTYAML
    assert "$output" "=~" \
        "Error: short-name resolution enforced but cannot prompt without a TTY|Resolving \"$userimage\" using unqualified-search registries" \
        "The error message does match any of the expected ones"

I will wipe this off my worry list unless/until I hear otherwise.

[Luap99]

If it causes flakes then it is a concern. Maybe not bad enough to fix immediately but I will start documenting them in https://issues.redhat.com/browse/RUN-2202 so we know what needs to be addressed to remove such network flakes in the future.