Description
The test job in ci.yml currently builds the binary to /dev/null:
- name: Build
run: go build -o /dev/null ./cmd/opencodereview
This only verifies that the code compiles, but does not verify that the resulting binary:
- Starts without panicking (e.g., bad
init() functions, missing linked symbols)
- Has correct ldflags injection (
--version output)
- Has intact flag registration and dispatch logic (
--help output)
Proposed Change
Replace the current Build step and add a Smoke Test step in the existing test job:
- name: Build
run: go build -o ./opencodereview ./cmd/opencodereview
- name: Smoke test
run: |
./opencodereview --version
./opencodereview --version | grep -q "open-code-review"
./opencodereview --help
./opencodereview --help | grep -q "Commands:"
Why steps in the existing job (not a separate job)?
- The smoke test itself takes <1 second — spinning up a new container just for this is wasteful.
- No artifact passing needed — build and verify in the same job is simplest.
- Semantically it's a natural extension of "Build": compile it, then prove it runs.
Scope
- File:
.github/workflows/ci.yml
- Job:
test (lines 69–70)
- The
cross-compile job should remain unchanged (cross-compiled binaries can't run on the host architecture).
Acceptance Criteria
Context
Discovered during a CI gap analysis. The cross-compile job also builds to /dev/null, but that's expected — you can't execute a darwin/arm64 binary on a linux/amd64 runner. The native-platform test job is the right place to verify the binary actually works.
Description
The
testjob inci.ymlcurrently builds the binary to/dev/null:This only verifies that the code compiles, but does not verify that the resulting binary:
init()functions, missing linked symbols)--versionoutput)--helpoutput)Proposed Change
Replace the current Build step and add a Smoke Test step in the existing
testjob:Why steps in the existing job (not a separate job)?
Scope
.github/workflows/ci.ymltest(lines 69–70)cross-compilejob should remain unchanged (cross-compiled binaries can't run on the host architecture).Acceptance Criteria
testjob builds a real binary (not to/dev/null)--versionoutputs a string containingopen-code-review--helpoutputs a string containingCommands:Context
Discovered during a CI gap analysis. The cross-compile job also builds to
/dev/null, but that's expected — you can't execute adarwin/arm64binary on alinux/amd64runner. The native-platformtestjob is the right place to verify the binary actually works.