Make alerting survive -e and always write the run summary

[danielhanchen]

I dispatched the repin bot to exercise its main body, which had only ever hit its skip branch. The bot worked. The alerting underneath it did not, and it turns out none of it ever has.

Two compounding bugs.

The step aborted before it could report anything. The action runs set -uo pipefail with a comment saying alerting must never fail the run it reports on. But GitHub invokes shell: bash as /usr/bin/bash --noprofile --norc -e -o pipefail, and set -uo pipefail does not undo the -e that is already in effect. So the first non-zero command killed the step with no output at all, which is why the failure looked like a mystery exit 1 rather than a diagnosable error. Now set +e explicitly, and the script ends in exit 0.

Issues are disabled on this repository. has_issues=false, which is the default for a fork. Every alert this pipeline can raise ends in gh issue create, so every one of them would have failed silently. The success path returns early without touching the API, which is why the preflight and dead-man runs have all been green and nothing looked wrong. My reports of "no open prebuilt-failure issues" were vacuous; there could never have been any.

So the alert now writes to $GITHUB_STEP_SUMMARY before trying the API. That needs no token, no permission and no repository setting, so the details are always readable on the run page even when the issue cannot be opened. If creation then fails, the error message names the cause instead of guessing:

::error::prebuilt-alert: issues are disabled on unslothai/llama.cpp, so llama-repin-bot cannot be tracked; see the run summary for details

I also stopped discarding gh issue create's stderr, so the real API message reaches the log, and switched the success test from "output is non-empty" to "output is a URL", since the previous check treated an error message as success.

This makes failures visible. It does not make them tracked. Enabling Issues on the fork is a call for you rather than me, since a fork of a project this popular will attract bug reports meant for upstream. Until then the run summary is the alert.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: b563974243

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Shorten the run-summary comment

This four-line comment includes incident-specific prose such as "the failure this whole pipeline keeps having" and is excessive for the simple fallback write that follows. Reduce it to a concise explanation that the summary preserves failure details when issue reporting is unavailable.

AGENTS.md reference: AGENTS.md:L63-L63

Useful? React with 👍 / 👎.