fix(release): use ref_name for gh run list branch so RUN_ID is resolved

[plavjanik]

Summary

Nightly SDK packages (e.g. zowe-native-proto-sdk-0.3.0-2026-03-18-014027.tgz) were bundling a server PAX that contained the wrong binary names (zowed / libzowed.so instead of zowex). After install, the SDK runs ~/.zowe-server/zowex server, so the shell reported FSUM7351 not found. The PAX also had stale build timestamps (e.g. March 6) instead of a recent main build.

This change fixes the root cause: the nightly release workflow was resolving RUN_ID with gh run list --branch=${{ github.ref }}. For scheduled runs, github.ref is refs/heads/main, but gh run list --branch=refs/heads/main returns no runs (the CLI expects the short branch name main). So RUN_ID was empty.

What happened when RUN_ID was empty

The "Download Server" step runs:

gh run download $RUN_ID --dir packages/sdk/bin --name zowe-server-bin
gh run download $RUN_ID --name zowe-server-release

With RUN_ID empty, this becomes gh run download --name zowe-server-bin (and similarly for the second). Per gh behavior, that downloads the latest artifact with that name from any workflow run, not from a specific branch.

The most recent such artifact was from run 22771182462 on branch member-ispf-stats (March 6, 2026). That branch's buildTools.ts still packaged the old layout: zowed and libzowed.so. So the nightly was shipping a PAX from a feature branch with old naming instead of from a main z/OS build.

Fix

Use github.ref_name instead of github.ref when calling gh run list:

• github.ref = refs/heads/main → gh run list returns nothing → RUN_ID empty.
• github.ref_name = main → gh run list returns the latest z/OS build run for main → RUN_ID set correctly.

So the nightly now resolves RUN_ID from the main branch's z/OS build (when one exists).

Verification

• This repo: Confirmed locally that gh run list --branch=refs/heads/main --workflow=zos-build.yml --limit=1 returns [], while gh run list --branch=main --workflow=zos-build.yml --limit=1 returns a run ID.
• Nightly: After merge, the next scheduled release run will use the new logic; if there is a successful z/OS build on main, that run's artifacts will be used for the SDK/server PAX.
• Note: z/OS build on main has been failing/cancelled since around the ibm-clang migration (Migrate native C++ code to use ibm-clang compiler #812). Fixing those failures is separate; this PR only ensures the release workflow uses the correct run (main) when one exists, instead of falling back to the latest artifact from any branch.

Follow-up

• Investigate and fix why the z/OS build on main has been failing (so nightly can ship a current server from main).

Checklist

• One-line change in .github/workflows/release.yml (line 62).
• No change to build or z/OS build workflows; only the release workflow's "Set Environment" step is affected.
• Commit is signed off.
• Checked: no existing PR or issue tracks this RUN_ID/ref_name fix or the nightly wrong-artifact behavior (PR Fix upload step of release workflow #813 was a different release workflow fix).

Made with Cursor

[github-actions]

Client artifacts:

• CLI Plug-in: https://github.com/zowe/zowe-native-proto/actions/runs/23247819842/artifacts/5986365300
• VSCode Extension: https://github.com/zowe/zowe-native-proto/actions/runs/23247819842/artifacts/5986365689
• SDK: https://github.com/zowe/zowe-native-proto/actions/runs/23247819842/artifacts/5986366081

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[t1m0thyj]

The z/OS Build workflow is temporarily broken after our switch to ibm-clang compiler. We're waiting on Marist to apply maintenance to the build system, which is scheduled for sometime in April.

Unfortunately this means that at the moment we have no way of building the ZRS binaries and packaging new releases with public infrastructure.

I've disabled the z/OS Build workflow for the time being. As a backup, we should be able to build using internal CI for now - I'll follow up offline with more details.