GitHub Action Workflow images step is failing due to aws-cli build

[mikeshng]

Describe the bug
In #729 we introduced a new Dockerfile and image. It's now failing in our GitHub Action Workflow image building and pushing step. See below for more details:

https://github.com/open-cluster-management-io/ocm/actions/runs/12162714239/job/33920318125

imagebuilder --allow-pull -t quay.io/open-cluster-management/aws-cli:latest-arm64 -f ./build/Dockerfile.aws-cli --build-arg OS=linux --build-arg ARCH=arm64 .
--> FROM golang:1.22-bullseye as builder
--> ARG OS=linux
--> ARG ARCH=x86_64
--> ARG VERSION=2.22.8
--> WORKDIR /tmp
--> RUN apt-get update
Get:1 http://deb.debian.org/debian bullseye InRelease [116 kB]
Get:2 http://deb.debian.org/debian-security bullseye-security InRelease [27.2 kB]
Get:3 http://deb.debian.org/debian bullseye-updates InRelease [44.1 kB]
Get:4 http://deb.debian.org/debian bullseye/main amd64 Packages [8066 kB]
Get:5 http://deb.debian.org/debian-security bullseye-security/main amd64 Packages [317 kB]
Get:6 http://deb.debian.org/debian bullseye-updates/main amd64 Packages [18.8 kB]
Fetched 8589 kB in 1s (7197 kB/s)
Reading package lists...
--> RUN apt-get install unzip
Reading package lists...
Building dependency tree...
Reading state information...
Suggested packages:
  zip
The following NEW packages will be installed:
  unzip
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 172 kB of archives.
After this operation, 393 kB of additional disk space will be used.
Get:1 http://deb.debian.org/debian bullseye/main amd64 unzip amd64 6.0-26+deb11u1 [172 kB]
debconf: delaying package configuration, since apt-utils is not installed
Fetched 172 kB in 0s (5266 kB/s)
Selecting previously unselected package unzip.
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 15725 files and directories currently installed.)
Preparing to unpack .../unzip_6.0-26+deb11u1_amd64.deb ...
Unpacking unzip (6.0-26+deb11u1) ...
Setting up unzip (6.0-26+deb11u1) ...
--> RUN unzip -v
UnZip 6.00 of 20 April 2009, by Debian. Original by Info-ZIP.
Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip/ ;
see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites.
Compiled with gcc 10.2.1 20210[110](https://github.com/open-cluster-management-io/ocm/actions/runs/12162714239/job/33920318125#step:6:111) for Unix (Linux ELF).
UnZip special compilation options:
        ACORN_FTYPE_NFS
        COPYRIGHT_CLEAN (PKZIP 0.9x unreducing method not supported)
        SET_DIR_ATTRIB
        SYMLINKS (symbolic links supported, if RTL and file system permit)
        TIMESTAMP
        UNIXBACKUP
        USE_EF_UT_TIME
        USE_UNSHRINK (PKZIP/Zip 1.x unshrinking method supported)
        USE_DEFLATE64 (PKZIP 4.x Deflate64(tm) supported)
        UNICODE_SUPPORT [wide-chars, char coding: other] (handle UTF-8 paths)
        LARGE_FILE_SUPPORT (large files over 2 GiB supported)
        ZIP64_SUPPORT (archives using Zip64 for large files supported)
        USE_BZIP2 (PKZIP 4.6+, using bzip2 lib version 1.0.8, 13-Jul-2019)
        VMS_TEXT_CONV
        WILD_STOP_AT_DIR
        [decryption, version 2.11 of 05 Jan 2007]
UnZip and ZipInfo environment options:
           UNZIP:  [none]
        UNZIPOPT:  [none]
         ZIPINFO:  [none]
      ZIPINFOOPT:  [none]
--> RUN curl "https://awscli.amazonaws.com/awscli-exe-${OS}-${ARCH}-${VERSION}.zip" -o "awscliv2.zip"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100  6220  100  6220    0     0  17720      0 --:--:-- --:--:-- --:--:-- 17720
100  6220  100  6220    0     0  17720      0 --:--:-- --:--:-- --:--:-- 17670
--> RUN unzip awscliv2.zip
  End-of-central-directory signature not found.  Either this file is not
Archive:  awscliv2.zip
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
unzip:  cannot find zipfile directory in one of awscliv2.zip or
        awscliv2.zip.zip, and cannot find awscliv2.zip.ZIP, period.
running 'unzip awscliv2.zip' failed with exit code 9
make: *** [Makefile:73: image-aws-cli] Error 1
Error: The operation was canceled.

To Reproduce
When PRs get merged.

Expected behavior
Image build and push sccessfully.

Environment ie: OCM version, Kubernetes version and provider:

Additional context

[dosubot]

@mikeshng Hello there! I'm here to help you with bug fixes, answer questions, and guide you on becoming a contributor. If you need assistance, feel free to ask!

The issue you're encountering seems to be related to the architecture mismatch when downloading the AWS CLI zip file. The Dockerfile is set to use ARCH=x86_64, but the GitHub Actions workflow is attempting to build for the arm64 architecture. This mismatch could lead to downloading an incorrect or non-existent file, resulting in the corrupted zip file error.

To resolve this, ensure that the ARCH argument in the Dockerfile matches the architecture specified in the GitHub Actions workflow. You can modify the Dockerfile to use the correct architecture by setting ARG ARCH=arm64 if the workflow is building for arm64. Additionally, verify that the URL used for downloading the AWS CLI zip file is correct for the specified architecture. The URL format should be:

https://awscli.amazonaws.com/awscli-exe-${OS}-${ARCH}-${VERSION}.zip

Make sure that ${ARCH} is correctly set to arm64 when building for that architecture. Adjusting these settings should help resolve the issue with the corrupted zip file.

To continue talking to Dosu, mention @dosu.

[jaswalkiranavtar]

Looks like it is failure because for arm archirecture the image expects ARCH to be set to aarch64 as mentioned here, where as the GH workflow is setting to arm64.

[jaswalkiranavtar]

Created PR: #738

[qiujian16]

/close

[openshift-ci]

@qiujian16: Closing this issue.

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.