Release
successCheckout <1s
successSet up Go 6s
successgo test 31s
go test ./... -count=1
successBuild the binaries 1m37s
bash ./02-build-releases.sh "${GITHUB_REF_NAME}"successRelease notes <1s
set -euo pipefail
message="$(git for-each-ref "refs/tags/${GITHUB_REF_NAME}" --format='%(contents)' | sed '/^-----BEGIN PGP SIGNATURE-----/,$d')"
if [ -z "$(printf '%s' "${message}" | tr -d '[:space:]')" ]; then
message="Mini Me ${GITHUB_REF_NAME}"
fi
{
printf '%s\n\n' "${message}"
echo "- Commit: \`${GITHUB_SHA}\`"
echo "- Built by the Release workflow, run #${GITHUB_RUN_NUMBER}, with $(go env GOVERSION)"
echo
echo '## Checksums'
echo
echo '```'
cat "release/${GITHUB_REF_NAME}/SHA256SUMS"
echo '```'
} > "${RUNNER_TEMP}/notes.md"
echo "path=${RUNNER_TEMP}/notes.md" >> "$GITHUB_OUTPUT"
successKeep the binaries as a run artifact 11s
successPublish the release 9s
No test reports for this run.
Tell a job where its test runner writes its report and this tab fills in: how many tests passed, failed and were skipped, a bar of the result at a glance, then every failure first — with the assertion that failed and the output around it — over a per-suite list of cases and their durations. No scrolling a log for the word FAIL.
It is one reports: key on the job — a job key, not a step, so the report is collected whatever the job concluded. JUnit XML and go test -json are both understood, and most runners already emit one of them. reports: is a rickub extension and works only in .rickub/workflows/; in .github/workflows/ it is a parse error on purpose, because those files are also meant to run on github.com.