[FSSDK-12919] Replace deprecated hub CLI with gh in release workflow

[Mat001]

Problem

Agent GitHub releases ship with no binary assets (v4.4.0 and v4.5.0 both have 0 assets). The release workflow attaches the generate_secret binary using the deprecated hub CLI, which is not installed on GitHub-hosted runners → hub: command not found (exit 127). DockerHub image pushes succeed, but the release-asset step fails and turns the build_upload_publish_draft job red.

Fix

Replace hub with gh, which is preinstalled on all GitHub-hosted runners:

• scripts/ci_attach_generate_secret.sh: hub release edit -a → gh release upload --clobber (keeps per-asset display labels via gh's path#label syntax).
• scripts/ci_create_github_release.sh (new): a gh-based, idempotent replacement for travisci-tools/release_github/release_github_v2.sh. Same CHANGELOG.md parsing for release notes; uses gh release create --draft.
• .github/workflows/agent.yml:
  • Removed both install_hub.sh steps and their now-unused optimizely/travisci-tools checkouts.
  • hub release download -i → gh release download -p in the asset-verification job.

Two robustness fixes beyond a literal swap

1. Idempotent create — the tag push that triggers CI normally comes from a GitHub release created in the UI, so the release usually already exists; a plain gh release create would fail just like hub did. The new script checks gh release view first and skips creation, letting the upload proceed.
2. Consistent tag — the old workflow passed $APP_VERSION (no v) to the create script but $RELEASE_TAG (v4.5.0) to the attach script. Both now use $RELEASE_TAG, matching the actual v-prefixed tag format.

Verification

• Bash syntax checked on both scripts; workflow YAML validated.
• Confirmed against the real gh CLI that release upload supports #label, release download supports -p, and both support --clobber.
• No hub / install_hub / release_github_v2 / travisci-tools references remain in the release jobs.
• Verified release_github_v2.sh is self-contained (no other sourced files), so nothing else is lost by dropping the travisci-tools dependency in the release path. (integration_test.yml still uses travisci-tools for its trigger script — intentionally untouched.)

The only true end-to-end test is the next tagged release.

https://optimizely-ext.atlassian.net/browse/FSSDK-12919

🤖 Generated with Claude Code

[pvcraven]

Kimi feedback. Thoughts?

Suggestions (non-blocking)

1. scripts/ci_create_github_release.sh

   • Add set -e (or set -euo pipefail) alongside set -o pipefail. Right now a failing grep/awk won’t stop the script.
   • Quote ${CHANGELOG} and consider an explicit [[ -f "${CHANGELOG}" ]] check before parsing.
   • Consider writing the extracted notes to a temp file and using gh release create ... --notes-file <file> instead of --notes "${DESCRIPTION}". Since DESCRIPTION is a changelog body, double-quoting it means backticks and $ will be shell-expanded/parsed, which is risky for release notes.

2. .github/workflows/agent.yml

   • The HOME: 'home/runner' env override is now unused in the create and upload packages and run script steps. Removing it would avoid confusion about why $HOME is being overridden.
   • On the Windows verification runner the step uses shell: bash, which is fine because gh is preinstalled and Git Bash provides tar.

Question

• The new create script only creates a release when gh release view says it doesn’t exist, and it creates it as --draft. If a tag is pushed directly (not from the GitHub UI), the release will be created as a draft and assets will attach, but it will remain unpublished until someone manually publishes it. Is that the intended behavior? It matches the old wording, but worth confirming.

[Mat001]

Thanks @pvcraven — addressed all the suggestions in c955a67.

scripts/ci_create_github_release.sh

• ✅ set -o pipefail → set -eo pipefail. (Left -u off intentionally so the $# -ne 1 usage message still fires cleanly; also moved the arg-count check above the GIT_TAG="$1" assignment.)
• ✅ Quoted "${CHANGELOG}" in all grep/awk calls and added an explicit [[ -f "${CHANGELOG}" ]] guard before parsing.
• ✅ Switched to --notes-file. DESCRIPTION is captured via $(...) (so its contents aren't re-parsed by the shell), then written with printf '%s\n' to a mktemp file that's cleaned up via an EXIT trap, and passed as --notes-file. Avoids any backtick/$ edge cases and arg-length limits.

.github/workflows/agent.yml

• ✅ Removed the now-unused HOME: 'home/runner' override. (Note: only the create and upload packages step still had it — the run script step's HOME was on the deleted install_hub step, so nothing to change there.)
• 👍 Confirmed on the Windows verification runner: shell: bash + preinstalled gh + Git Bash tar all work.

Question — draft behavior
Intended, and it matches the prior hub-based behavior (release_github_v2.sh used hub release create -d). In practice agent releases are created from the GitHub UI first (published), so gh release view finds the existing release and the create is skipped entirely — assets attach to the already-published release. The --draft path only applies to a bare git push --tags, which isn't how we cut agent releases; keeping it as a draft there is the safer default (matches old behavior, avoids auto-publishing an unreviewed release). Happy to switch it to publish-on-create if you'd prefer, but I'd lean toward leaving it as-is.

[pvcraven]

Thanks for addressing my earlier comments. This looks good to me.