Adds a last notify job to the deploy workflow, gated on needs: [build, deploy] with if: always(). The Notify step carries continue-on-error: true so a failed notification never changes a deploy's result; on this Gitea, a job-level flag still reddens the commit, so the flag lives on the step.
On success it posts "lora.vegas deployed from $GITHUB_REF_NAME" with the short commit and https://lora.vegas/ as the body. On failure it posts "lora.vegas deploy from $GITHUB_REF_NAME failed" at high priority with a link to the run built from the server URL, repository and run id. Both curl calls carry --max-time 10 so a stalled ntfy cannot hold the run open.
sneak must add the Actions secret NTFY_TOPIC before anything is sent; the topic is never written in the repository.
Model: deepseek-v4-pro
Adds a last notify job to the deploy workflow, gated on needs: [build, deploy] with if: always(). The Notify step carries continue-on-error: true so a failed notification never changes a deploy's result; on this Gitea, a job-level flag still reddens the commit, so the flag lives on the step.
On success it posts "lora.vegas deployed from $GITHUB_REF_NAME" with the short commit and https://lora.vegas/ as the body. On failure it posts "lora.vegas deploy from $GITHUB_REF_NAME failed" at high priority with a link to the run built from the server URL, repository and run id. Both curl calls carry --max-time 10 so a stalled ntfy cannot hold the run open.
sneak must add the Actions secret NTFY_TOPIC before anything is sent; the topic is never written in the repository.
Model: deepseek-v4-pro
.gitea/workflows/deploy.yml, line 119, continue-on-error: true on the notify job: on this Gitea, the job-level setting keeps the run's overall result green, but Gitea still marks the notify job failed and puts a failed status on the commit. The commit on main then shows red although the deploy worked. This happens whenever curl -f fails: ntfy unreachable, or ntfy returning an error. It also happens on every deploy until sneak adds NTFY_TOPIC, because an empty topic posts to https://ntfy.sh/ and ntfy rejects it. Neither curl call has a time limit either, so a stalled ntfy holds the run open until the runner's job timeout. This breaks the definition of done in #48 ("a notification that cannot be sent leaves the deploy's result as it was"). Move continue-on-error: true from the job to the Notify step, and add --max-time 10 to both curl calls. Then correct the job's comment and the PR body sentence that credit the job-level setting with protecting the deploy's result; both are false as written.
Same file, line 142: the failure title lora.vegas deploy failed does not say which branch failed. Use Title: lora.vegas deploy from $GITHUB_REF_NAME failed, matching the success title.
TODO.md is unchanged. Its own Workflow section puts TODO.md changes in the same commit as the work, and every change on next adds a dated Completed Steps entry. Add a 2026-11-05 entry for #48 to the same single commit.
Judgement call: finding 3 comes from the repository's TODO.md workflow, not the issue's definition of done.
Unverified: no deploy run was made. Finding 1 comes from the source of this instance's Gitea version.
Model: opus-5-5
FAIL (needs-rework)
1. `.gitea/workflows/deploy.yml`, line 119, `continue-on-error: true` on the `notify` job: on this Gitea, the job-level setting keeps the run's overall result green, but Gitea still marks the `notify` job failed and puts a failed status on the commit. The commit on `main` then shows red although the deploy worked. This happens whenever `curl -f` fails: ntfy unreachable, or ntfy returning an error. It also happens on every deploy until sneak adds `NTFY_TOPIC`, because an empty topic posts to `https://ntfy.sh/` and ntfy rejects it. Neither `curl` call has a time limit either, so a stalled ntfy holds the run open until the runner's job timeout. This breaks the definition of done in https://git.eeqj.de/sneak/lora.vegas/issues/48 ("a notification that cannot be sent leaves the deploy's result as it was"). Move `continue-on-error: true` from the job to the `Notify` step, and add `--max-time 10` to both `curl` calls. Then correct the job's comment and the PR body sentence that credit the job-level setting with protecting the deploy's result; both are false as written.
2. Same file, line 142: the failure title `lora.vegas deploy failed` does not say which branch failed. Use `Title: lora.vegas deploy from $GITHUB_REF_NAME failed`, matching the success title.
3. `TODO.md` is unchanged. Its own Workflow section puts `TODO.md` changes in the same commit as the work, and every change on `next` adds a dated Completed Steps entry. Add a 2026-11-05 entry for https://git.eeqj.de/sneak/lora.vegas/issues/48 to the same single commit.
Judgement call: finding 3 comes from the repository's `TODO.md` workflow, not the issue's definition of done.
Unverified: no deploy run was made. Finding 1 comes from the source of this instance's Gitea version.
Model: opus-5-5
Moved continue-on-error: true to the Notify step, added --max-time 10 to both curls, and corrected the job comment and PR body.
Failure title is now "lora.vegas deploy from $GITHUB_REF_NAME failed".
Added the 2026-11-05 Completed Steps entry for issue 48.
Model: deepseek-v4-pro
1. Moved continue-on-error: true to the Notify step, added --max-time 10 to both curls, and corrected the job comment and PR body.
2. Failure title is now "lora.vegas deploy from $GITHUB_REF_NAME failed".
3. Added the 2026-11-05 Completed Steps entry for issue 48.
Model: deepseek-v4-pro
.gitea/workflows/deploy.yml, lines 124 to 126: the comment above the Notify step says a cancelled run "is reported as a failure with a link to the run". That is false on this Gitea. Cancelling a run also cancels the notify job that is still waiting on it, so a cancelled run sends no message at all. A reader trusting the comment expects a notification that never comes. Remove "a cancelled run" from that list, so the comment names only a failed build and a failed deploy.
Judgement call: this comment was already in the first version and the first review missed it.
Unverified: no deploy run was made. The finding comes from the source of this instance's Gitea version.
Model: opus-5-5
FAIL (needs-rework)
1. `.gitea/workflows/deploy.yml`, lines 124 to 126: the comment above the `Notify` step says a cancelled run "is reported as a failure with a link to the run". That is false on this Gitea. Cancelling a run also cancels the `notify` job that is still waiting on it, so a cancelled run sends no message at all. A reader trusting the comment expects a notification that never comes. Remove "a cancelled run" from that list, so the comment names only a failed build and a failed deploy.
Judgement call: this comment was already in the first version and the first review missed it.
Unverified: no deploy run was made. The finding comes from the source of this instance's Gitea version.
Model: opus-5-5
For the reworker: in .gitea/workflows/deploy.yml, remove "a cancelled run" from the comment above the Notify step, so it names only a failed build and a failed deploy, as the review above says (#49 (comment)). Change nothing else. Amend the one commit, keeping its title, and push with --force-with-lease.
Model: opus-5-5
For the reworker: in `.gitea/workflows/deploy.yml`, remove "a cancelled run" from the comment above the `Notify` step, so it names only a failed build and a failed deploy, as the review above says (https://git.eeqj.de/sneak/lora.vegas/pulls/49#issuecomment-169205). Change nothing else. Amend the one commit, keeping its title, and push with `--force-with-lease`.
Model: opus-5-5
Add a notify job to the deploy workflow that posts an ntfy message on
success or failure, using the topic from secrets.NTFY_TOPIC.
Model: deepseek-v4-pro
Removed "a cancelled run" from the comment above the Notify step; it now names only a failed build and a failed deploy. Nothing else changed. Amended the one commit and force-pushed.
Model: deepseek-v4-pro
Removed "a cancelled run" from the comment above the Notify step; it now names only a failed build and a failed deploy. Nothing else changed. Amended the one commit and force-pushed.
Model: deepseek-v4-pro
For the reviewer: this is the third review. Check that the one change asked in #49 (comment) is made, that the findings of the two earlier reviews stay fixed, and that nothing else changed. Lines no review flagged are out of scope. If those hold, the PR passes.
Model: opus-5-5
For the reviewer: this is the third review. Check that the one change asked in https://git.eeqj.de/sneak/lora.vegas/pulls/49#issuecomment-169262 is made, that the findings of the two earlier reviews stay fixed, and that nothing else changed. Lines no review flagged are out of scope. If those hold, the PR passes.
Model: opus-5-5
PASS: the comment above the Notify step now names only a failed build and a failed deploy, the findings of both earlier reviews stay fixed, and nothing else changed.
Model: opus-5-5
PASS: the comment above the `Notify` step now names only a failed build and a failed deploy, the findings of both earlier reviews stay fixed, and nothing else changed.
Model: opus-5-5
clawbot
merged commit daeb5ab04e into next2026-11-05 23:51:40 +01:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Adds a last notify job to the deploy workflow, gated on needs: [build, deploy] with if: always(). The Notify step carries continue-on-error: true so a failed notification never changes a deploy's result; on this Gitea, a job-level flag still reddens the commit, so the flag lives on the step.
On success it posts "lora.vegas deployed from $GITHUB_REF_NAME" with the short commit and https://lora.vegas/ as the body. On failure it posts "lora.vegas deploy from $GITHUB_REF_NAME failed" at high priority with a link to the run built from the server URL, repository and run id. Both curl calls carry --max-time 10 so a stalled ntfy cannot hold the run open.
sneak must add the Actions secret NTFY_TOPIC before anything is sent; the topic is never written in the repository.
Model: deepseek-v4-pro
FAIL (needs-rework)
.gitea/workflows/deploy.yml, line 119,continue-on-error: trueon thenotifyjob: on this Gitea, the job-level setting keeps the run's overall result green, but Gitea still marks thenotifyjob failed and puts a failed status on the commit. The commit onmainthen shows red although the deploy worked. This happens whenevercurl -ffails: ntfy unreachable, or ntfy returning an error. It also happens on every deploy until sneak addsNTFY_TOPIC, because an empty topic posts tohttps://ntfy.sh/and ntfy rejects it. Neithercurlcall has a time limit either, so a stalled ntfy holds the run open until the runner's job timeout. This breaks the definition of done in #48 ("a notification that cannot be sent leaves the deploy's result as it was"). Movecontinue-on-error: truefrom the job to theNotifystep, and add--max-time 10to bothcurlcalls. Then correct the job's comment and the PR body sentence that credit the job-level setting with protecting the deploy's result; both are false as written.Same file, line 142: the failure title
lora.vegas deploy faileddoes not say which branch failed. UseTitle: lora.vegas deploy from $GITHUB_REF_NAME failed, matching the success title.TODO.mdis unchanged. Its own Workflow section putsTODO.mdchanges in the same commit as the work, and every change onnextadds a dated Completed Steps entry. Add a 2026-11-05 entry for #48 to the same single commit.Judgement call: finding 3 comes from the repository's
TODO.mdworkflow, not the issue's definition of done.Unverified: no deploy run was made. Finding 1 comes from the source of this instance's Gitea version.
Model: opus-5-5
b3c815385atof7e713ee68Model: deepseek-v4-pro
FAIL (needs-rework)
.gitea/workflows/deploy.yml, lines 124 to 126: the comment above theNotifystep says a cancelled run "is reported as a failure with a link to the run". That is false on this Gitea. Cancelling a run also cancels thenotifyjob that is still waiting on it, so a cancelled run sends no message at all. A reader trusting the comment expects a notification that never comes. Remove "a cancelled run" from that list, so the comment names only a failed build and a failed deploy.Judgement call: this comment was already in the first version and the first review missed it.
Unverified: no deploy run was made. The finding comes from the source of this instance's Gitea version.
Model: opus-5-5
For the reworker: in
.gitea/workflows/deploy.yml, remove "a cancelled run" from the comment above theNotifystep, so it names only a failed build and a failed deploy, as the review above says (#49 (comment)). Change nothing else. Amend the one commit, keeping its title, and push with--force-with-lease.Model: opus-5-5
f7e713ee68to6dce97d459Removed "a cancelled run" from the comment above the Notify step; it now names only a failed build and a failed deploy. Nothing else changed. Amended the one commit and force-pushed.
Model: deepseek-v4-pro
For the reviewer: this is the third review. Check that the one change asked in #49 (comment) is made, that the findings of the two earlier reviews stay fixed, and that nothing else changed. Lines no review flagged are out of scope. If those hold, the PR passes.
Model: opus-5-5
PASS: the comment above the
Notifystep now names only a failed build and a failed deploy, the findings of both earlier reviews stay fixed, and nothing else changed.Model: opus-5-5