Current state
ci/notifications/notify-build-status.ts parses process.argv and assigns each value to a Record<string, string> (line 51), then casts each field to JobResult via as JobResult (lines 58–65) with no check that the value is a valid union member. Any string — including a typo, an empty value, or a misconfigured CI environment variable — is silently accepted as a well-typed JobResult and passed into buildBuildStatusMessage. The parseArgs return type promises BuildStatusInputs but delivers unvalidated data, making the function signature misleading to callers.
Ideal state
parseArgs validates each argument value against the JobResult union before assigning it — either via a Zod schema or an explicit membership check (["success", "failure", "skipped"].includes(value)).- An unrecognised value produces a descriptive error message naming the invalid argument and the expected members — not a silent cast.
- The return type is honest:
parseArgs either returns validated BuildStatusInputs or throws with a clear message.
- No
as JobResult assertions remain in the parsing path.
Out of scope
- Refactoring
buildBuildStatusMessage or the downstream notification logic.
Starting points
ci/notifications/notify-build-status.ts line 51 — the Record<string, string> accumulatorci/notifications/notify-build-status.ts lines 58–65 — the eight as JobResult casts
QA plan
- Pass an invalid job-status string (e.g.
"UNKNOWN") as one of the CLI arguments and run the script — expect a descriptive error naming the invalid value and listing valid JobResult members.
- Pass valid
JobResult values for all arguments — expect the script runs without error.
- Run
npx tsc --noEmit — expect zero type errors.
Done when
parseArgs validates all job-status arguments against the JobResult union and an invalid argument produces a named error instead of a silent cast.
Current state
ci/notifications/notify-build-status.tsparsesprocess.argvand assigns each value to aRecord<string, string>(line 51), then casts each field toJobResultviaas JobResult(lines 58–65) with no check that the value is a valid union member. Any string — including a typo, an empty value, or a misconfigured CI environment variable — is silently accepted as a well-typedJobResultand passed intobuildBuildStatusMessage. TheparseArgsreturn type promisesBuildStatusInputsbut delivers unvalidated data, making the function signature misleading to callers.Ideal state
parseArgsvalidates each argument value against theJobResultunion before assigning it — either via a Zod schema or an explicit membership check (["success", "failure", "skipped"].includes(value)).parseArgseither returns validatedBuildStatusInputsor throws with a clear message.as JobResultassertions remain in the parsing path.Out of scope
buildBuildStatusMessageor the downstream notification logic.Starting points
ci/notifications/notify-build-status.tsline 51 — theRecord<string, string>accumulatorci/notifications/notify-build-status.tslines 58–65 — the eightas JobResultcastsQA plan
"UNKNOWN") as one of the CLI arguments and run the script — expect a descriptive error naming the invalid value and listing validJobResultmembers.JobResultvalues for all arguments — expect the script runs without error.npx tsc --noEmit— expect zero type errors.Done when
parseArgsvalidates all job-status arguments against theJobResultunion and an invalid argument produces a named error instead of a silent cast.