Fix for mismatching cpu type for macos arm64 architecture

[bhanurp]

• All tests have passed. If this feature is not already covered by the tests, new tests have been added.
• The pull request is targeting the dev branch.
• The code has been validated to compile successfully by running go vet ./....
• The code has been formatted properly using go fmt ./....

---

🐛 Problem Statement

The execution of binary jf on macos arm64 is causing Bad CPU type in executable

🔍 Root Cause

The unzip command, by default, prompts the user when it encounters existing files. In non-interactive environments (like shell scripts or CI/CD runners), there is no stdin to provide an answer. This leads to a read error, causing unzip to default to [N]one, meaning it skips overwriting existing files silently. This PR should also fix #2960

✅ Fix Implemented

Added the -o flag to the unzip command to force overwrite of existing files without user interaction. As an alternative approach the binary can be deleted as well once upload is successful

jfrog-cli/Jenkinsfile

Line 547 in eee4967

def uploadSignedDarwinBinaries(goarch,pkg) {

📌 Notes

This is happening on jenkins release pipeline, CI script is packing from github uploading as artifact and jenkins pipelines is downloading the bin and uploading to releases.jfrog.io even though jfrog-cli binary is build properly for arm64 because of similar steps for x86 and arm64 binaries the artifact created as artifact.zip is with same name for arm64 and x86. Since x86 happens first and then arm64, unzip binary for arm64 fails since it is with same name. It should work even on arm64 with Rosetta installed.

below screen shot should show the difference from 2.73.2 this issue has started

[github-actions]

---

🐸 JFrog Frogbot

[EyalDelarea]

Great catch!