[rhuss]

Summary

Release automation, the nightly drift check, and the E2E lane for sdk-go. Stacked on the governance PR; review after it is merged. Draft until the E2E lane is green here and the ai-openshell-sdk-bot App exists (#2).

Core releases and SDK releases

• core-watch.yml (hourly, or dispatched with a tag): core-tags.sh lists core tags newer than the pin, and open-bump-pr.sh opens one proposal per tag on branch core/<tag>. Each proposal moves the pin in buf.gen.yaml, regenerates the bindings, refreshes the vendored conformance fixtures, and shows the proto diff between the two core tags. Labels: core-bump plus stable or prerelease. Only the newest pre-release of a train gets a proposal, a newer one closes older pre-release proposals, and stable proposals are never closed automatically.
• release-tag.yml (push to main, or dispatched for a commit): when a commit moves the pin to stable core vX.Y.Z, tag-release.sh tags vX.Y.Z, publishes the GitHub release with the merged proposal's body, and asks the Go module proxy for the version. Pre-release pins and other commits create nothing; a tag at another commit fails the run.

Drift

• core-drift.yml (nightly): drift-check.sh runs buf breaking from core main against the pin for the files the SDK generates, regenerates from main and builds, and lists RPCs the SDK doesn't call yet (informational). update-drift-issue.sh keeps one Core main drift issue current and closes it when the check passes. Failed automation runs add a dated line to that issue through report-failure.sh.

E2E

• e2e/: the Go E2E suite from test: E2E tests for Go SDK NVIDIA/OpenShell#3338 by @jiripetrlik, with his commit, plus one commit adapting it to CreateOption.
• e2e.yml: start-gateway.sh runs the published gateway with the Docker driver from core's own deploy/docker/docker-compose.yml and gateway.toml at the core tag, with the supervisor and sandbox images pinned to that version. ci.yml calls it for pull requests that change the pin, the bindings, the SDK code, the suite, or the gateway scripts.

The workflows that write to GitHub use the App token, scoped to the permissions each job needs, so their pushes and PRs trigger CI. They need the SDK_BOT_CLIENT_ID and SDK_BOT_PRIVATE_KEY secrets. workflows:check also runs shellcheck over hack/.

Testing

• mise run ci and mise run workflows:check pass locally.
• core-tags.sh against real core tags, and against a synthetic list for ordering (pre.10 after pre.2, v0.1.10 after v0.1.9).
• open-bump-pr.sh v0.1.7 --dry-run against a base pinned to v0.1.6: one commit, regenerated bindings, fixture report, and the proto diff in the body.
• tag-release.sh --dry-run: tags v0.1.7 at the pin commit; no-op for commits without a pin change and for pre-release pins.
• drift-check.sh against core main: pass. The breaking check reports a deliberately deleted field.
• Drift issue scripts against a stubbed gh: create, append a failure, keep pending failures across a passing report, close.
• start-gateway.sh up to the compose call (image check, files at v0.1.7, image pinning). The E2E lane itself runs for the first time on this PR.

Part of NVIDIA/OpenShell#5031.

[SDAChess]

Setting up the App now, with a few changes from #2:

• Name: ai-openshell-go-sdk, so the bot is ai-openshell-go-sdk[bot]. hack/automation/README.md still says ai-openshell-sdk-bot.
• Permissions: contents, pull requests and issues (read & write), plus metadata (read). No workflows: write: nothing in this PR touches .github/workflows/, and I'd rather the adaptation agent can't push workflow changes. We can revisit if adapt.yml really needs it.
• Client ID instead of App ID: app-id is deprecated in create-github-app-token v3.3.0. The secrets are SDK_BOT_CLIENT_ID and SDK_BOT_PRIVATE_KEY, used as client-id: ${{ secrets.SDK_BOT_CLIENT_ID }}.
• sdk-bot environment: the secrets go in an sdk-bot environment that only main can deploy to, not at repository level. As repository secrets, anyone who can push a branch could mint a bot token, push to a PR as the bot and then approve it, which gets around the last-push approval in main-integrity. Please add environment: sdk-bot to the jobs in core-watch.yml, release-tag.yml and core-drift.yml; they all run from main already. adapt.yml will need some thought there, since a label trigger runs in PR context.

I'll post here once the secrets are in.

[rhuss]

Thanks, all four make sense. Done in 8cda85b: client-id: ${{ secrets.SDK_BOT_CLIENT_ID }} in all three workflows, environment: sdk-bot on the core-watch, release-tag, and core-drift jobs, and the README names ai-openshell-go-sdk. The bot's git identity comes from the token's app slug, so the rename needs nothing else. I also rebased onto the current #5, which drops the old dco.yml. Agreed on adapt.yml: it comes later and gets its own design for the PR-context trigger.

[elezar]

I'm assuming that although tests are run in parallel, the TestMain is sequential meaning that this will be valid at the point where the tests start running?

[rhuss]

Yes. TestMain runs before any test starts, and tests (parallel ones included) only start inside m.Run(), so sharedClient and gatewayName are set by then and never written again.

[elezar]

As a general question: What would it take to be able to run the same "conformance" tests using each of the SDKs? Is this something that we think we can strive towards?

[rhuss]

I think it's worth aiming for. Today the SDKs share only data: the JSON fixtures in core's sdk/conformance/, which sdk-go vendors and checks against the pinned tag. Sharing behavior would need scenarios in a language-neutral form (steps plus expected results) and a small runner per SDK, or one runner that drives each SDK through a thin CLI shim. Core's openshell-conformance crate already has driver-agnostic scenarios for the CLI, which might be a starting point. It's a cross-SDK design question, so I'd take it to an issue in NVIDIA/OpenShell rather than this PR.

[elezar]

The design is careful: SHA-pinned actions, bot secrets scoped to an environment that only main can use, and --dry-run modes on the scripts. I read the workflows and hack/automation scripts in full. I only skimmed the Go E2E code, and I haven't run anything.

Should fix

1. open-bump-pr.sh reopens proposals that someone closed on purpose. It skips a tag only if the branch still exists on origin or a PR from it was merged. If a maintainer closes a proposal and deletes the branch, core-watch recreates it on the next hourly run. Add a --state closed check or a marker.
2. A transient API error looks like a deleted core tag. if ! gh api repos/$core_repo/git/ref/tags/$tag --silent 2>/dev/null treats any failure (rate limit, 5xx) as "tag gone" and runs gh pr close --delete-branch. Only treat a 404 as gone.
3. tag-release.sh can't recover from a half-finished release. It creates the tag, then the release. If the release step fails, a re-run sees "tag already points at $sha" and exits 0, so the release is never created. Check for the release separately.
4. Secret name mismatch. The description says SDK_BOT_APP_ID, but all three bot workflows read secrets.SDK_BOT_CLIENT_ID.

Worth considering

5. tag-release.sh only diffs $sha^..$sha. A rebase-merge, or several commits in one push, can miss a pin change that isn't the tip. Fine if squash-only is enforced; otherwise worth documenting.
6. The E2E path filter in ci.yml omits .github/workflows/e2e.yml, mise.toml and go.mod.
7. start-gateway.sh / stop-gateway.sh assume a throwaway CI host:
   • The header says stop "undoes everything", but it never removes gateways/e2e or active_gateway.
   • It docker rm -fs every container labelled openshell.sandbox_namespace=openshell.
   • Only the supervisor image pin is verified; the sandbox sed has no check.
   • The readiness wait only checks the gateway manifest, not the supervisor and sandbox images.
8. report-failure.sh and update-drift-issue.sh read-modify-write the issue body from different concurrency groups, so a failure line can be lost. Low probability.
9. The uncovered-RPC grep (\.${method}\() matches generic names such as .List( and .Delete(, so it under-reports. It's informational only.
10. Several open stable proposals branch from the same main; merging an older one after a newer one moves the pin backwards.
11. persist-credentials: true in core-watch leaves the write-scoped App token in .git/config for the rest of the job. Acceptable, but worth knowing.

Looks good

core-tags.sh version ordering, the port-pr.sh word-splitting fix, the shared fixture list in mise.toml, and inputs passed via env: rather than interpolated into run:.

[rhuss]

@SDAChess #6 is ready for review. I rebased it onto main after #5 was squash-merged. The code is identical to the version you saw yesterday, including the sdk-bot environment changes from 8cda85b.

CODEOWNERS sends .github/ and hack/automation/ to @ai-openshell/infra, so this needs an infra approval.

After it merges, I'll do two one-off dispatches:

1. release-tag.yml at 7cc0b94f (the feat!: make the SDK a standalone module at github.com/ai-openshell/sdk-go #4 merge commit), to tag SDK v0.1.7 to match core v0.1.7.
2. core-watch.yml with the newest v0.1.8 pre-release, which should open the first update PR. That is also the first run that uses the App token, so it shows whether the App is installed on sdk-go.

If both runs pass, I'll close #2.

[rhuss]

@elezar thanks for the careful pass. Changes are in 0617220..de002ec.

Should fix

1. 261776b: a tag is skipped when any PR from its branch exists, in any state. This also covers a case the review didn't name: a pre-release proposal closed as superseded (branch deleted) would have come back on the next hourly run.
2. 261776b: only an HTTP 404 counts as a deleted tag. Any other error fails the run and lands in the drift issue.
3. 2386235: the tag and the release are checked separately and the missing one is created, so a re-run finishes a half-done release.
4. Fixed in the description: the secrets are SDK_BOT_CLIENT_ID and SDK_BOT_PRIVATE_KEY.

Worth considering
5. Fixed rather than documented, since the repo allows rebase and merge commits (2386235): the push workflow passes github.event.before as --since, and the script compares the pins at both commits.
6. 5ac6985.
7. 7695dc3: the header says the scripts are for throwaway CI hosts and why; stop removes the e2e registration and the active-gateway pointer when it still names e2e; the sandbox image pin is checked like the supervisor's. The label-based cleanup and the gateway-only image wait stay. If a fresh tag's supervisor or sandbox image lags, the E2E run fails and can be re-run.
8. Leaving as is. A lost line needs two writers within seconds, and the run stays in the Actions history.
9. Agreed, it under-reports. A planned follow-up adds a filter list for RPCs an SDK never calls; I'll fix the matching there.
10. Two proposals change the same tag: line in buf.gen.yaml and the same generated files, so merging an older one after a newer one stops at a merge conflict instead of moving the pin silently.
11. Agreed. open-bump-pr.sh pushes with plain git push, so git needs the token. The job runs only on main through the sdk-bot environment and doesn't check out PR code.

Separately, de002ec renames the App in the automation README to ai-openshell-sdk-go, the name it was registered under.

The fixes came from an agent-assisted pass. Checked locally: mise run ci, workflows:check, dry runs of tag-release.sh (including the planned v0.1.7 dispatch) and open-bump-pr.sh v0.1.8-pre.2, and the non-404 error paths with an invalid token. CI, including E2E, is green on de002ec.

[elezar]

Checked the updates at de002ec against my earlier review: the four must-fix items (closed proposals reopening, non-404 errors treated as a deleted tag, half-finished releases, secret name) are fixed, and the optional items are fixed or reasonably declined. Thanks for the quick turnaround.