heavy-duty/stoke
7
1
Fork 1
Code Issues 1 Pull requests Projects Releases 3 Packages Wiki Activity Actions

scripts/publish-deb.sh — report the CI cause when the token is empty, not laptop advice, and cover it with a test #57

New issue
Closed
opened 2026-09-02 19:47:55 +00:00 by claude-bot-andresmgsl · 2 comments
claude-bot-andresmgsl commented 2026-09-02 19:47:55 +00:00
Member
Copy link

Context

.forgejo/workflows/release.yml's Publish to Debian registry step is the first outward-facing step of a release and the first one that can fail on credentials. When it fails on an empty token it prints, from scripts/publish-deb.sh L33:

error: no token. Set STOKE_TOKEN or run: stoke auth login

Both remedies it offers are laptop remedies. stoke auth login is interactive and writes a config file that does not survive the container; STOKE_TOKEN is set on that step — from secrets.RELEASE_TOKEN (release.yml L34-36) — and the actual fault is that the secret expanded to empty. The message names neither the secret nor the workflow.

This is not hypothetical. Run 735, the first and only time release.yml has ever fired, died at exactly this line on v1.4.0 (2026-09-01): 117/117 tests passed, the .deb built, and then the release stopped on a message that pointed at a laptop. v1.4.0 was published by hand as a result, which created a 409 wall on the registry that made the tag unrecoverable.

The same repository already does this correctly one step later: scripts/publish-release.sh L15 is RELEASE_TOKEN="${RELEASE_TOKEN:?RELEASE_TOKEN is required}" — it names the variable the workflow actually sets. The two scripts disagree about how to report the same class of failure, and the one that runs first is the one that misdirects.

Raised by @claude-lead-andresmgsl on #54 as "your call whether it rides with 1.5.0 or gets its own issue." Triage's call: its own issue. #56 must stay a version-and-notes PR whose diff is reviewable as exactly that, and a behaviour change in a release script does not belong in it. This ships independently and on its own schedule.

Spec — decisions

Keep the two-source auth exactly as it is. L29-31 resolve STOKE_TOKEN first and fall back to the stoke auth login config; both paths are real and both stay. This issue changes one message and adds the test that was never written — it does not change how the token is found, what is uploaded, or any exit code.

One message that names both contexts, with no CI detection. Do not branch on CI/GITHUB_ACTIONS: a branch adds a code path whose wrong side is invisible in exactly the environment that matters. One message serves both readers, and the CI cause goes first because that is where this script fails in practice:

error: no token.
  In CI this step reads STOKE_TOKEN from secrets.RELEASE_TOKEN — an empty value here
  means the secret is unset or unreadable by this workflow, not that the tool is missing.
  Locally: export STOKE_TOKEN, or run `stoke auth login`.

Wording is the builder's to polish; the three facts are not optional: the variable read (STOKE_TOKEN), the secret it comes from in CI (RELEASE_TOKEN), and that an empty value means the secret — not the tooling — is the fault. Keep the error: prefix and stderr, and keep exit 1.

Update the header comment in the same commit. L11-13 documents the auth order as a two-item list with no mention of CI; add the secret to it, so the file's own documentation and its error message say the same thing.

Add test/publish-deb.test.js. This script has no test file — grep -rl publish-deb test/ returns nothing, while its sibling publish-release.sh has test/publish-release.test.js. That file is the pattern to copy: run the real script in a temp HOME/config so no real token is reachable, and assert on captured stderr and the exit code. This is the deliverable that makes the change provable rather than merely plausible.

Out of scope

  • The 409 and other status handling at L42-49. Untouched.
  • curl's response file at /tmp/stoke-publish-response.$$. A real wart, not this one.
  • Anything in publish-release.sh. It already reports correctly and is the exemplar here, not the patient.
  • The secret itself. @andres set RELEASE_TOKEN at the heavy-duty org level on 2026-09-02, so this message is now expected to go unread on the happy path — which is the point: it must be right for the next time it is read, not for the last time.

Tasks

  • Replace the L33 failure message per the Spec, keeping error: on stderr and exit 1.
  • Extend the L11-16 header comment to name secrets.RELEASE_TOKEN as the CI source of STOKE_TOKEN.
  • Add test/publish-deb.test.js, modelled on test/publish-release.test.js.
  • Add a changelog.d/ fragment for this change.
  • Open the PR with Refs, and let triage close this issue — the criteria are all pre-merge, so a Closes would also be correct; use whichever, but do not leave the issue open with everything ticked.

Acceptance criteria

  • Running scripts/publish-deb.sh <a real .deb path> with STOKE_TOKEN unset and no stored config exits 1, prints nothing on stdout, and prints a stderr message naming all three of STOKE_TOKEN, RELEASE_TOKEN, and the fact that an empty value points at the secret.
  • The message does not tell a CI reader to run stoke auth login as the primary remedy; the local remedy is present but second.
  • test/publish-deb.test.js exists and covers, at minimum: the empty-token failure above; and that a non-empty STOKE_TOKEN gets past the L33 guard — proving the guard was not tightened into a false positive. The token value must not appear in anything the test captures.
  • git diff touches exactly scripts/publish-deb.sh, test/publish-deb.test.js and one changelog.d/*.md. No change to release.yml, publish-release.sh, or the upload/status logic at L35-49.
  • npm test passes and ci / test is green on the PR head.

Test plan

npm test is the proof. The cases that must fail:

  • A stub run with STOKE_TOKEN set to a non-empty value that still exits 1 at the guard means the guard was broken, not improved.
  • A message that names RELEASE_TOKEN but drops STOKE_TOKEN is a regression for the local reader — the script does not read RELEASE_TOKEN, and saying so alone would send a laptop user to set a variable that has no effect.
  • Any test that requires network or a real registry is out of contract: this guard fires before the curl at L38, and the test must not reach it.

Dependencies

No blockers. Deliberately not a blocker on #56 and not blocked by it — the two touch different files, and holding the 1.5.0 tag for a message change would invert the priorities. If both are in flight, whichever merges second rebases; there is no shared line.

Related: #54, which named publish-deb.sh an explicit non-goal of its conversion, and #32, whose release is the one this message misdirected.

## Context `.forgejo/workflows/release.yml`'s *Publish to Debian registry* step is the **first outward-facing step of a release** and the first one that can fail on credentials. When it fails on an empty token it prints, from [`scripts/publish-deb.sh` L33](https://forgejo.heavyduty.builders/heavy-duty/stoke/src/commit/d6a21c9d9e1a4699d4b07cc76aecaac5ab31e847/scripts/publish-deb.sh#L33): ``` error: no token. Set STOKE_TOKEN or run: stoke auth login ``` Both remedies it offers are laptop remedies. `stoke auth login` is interactive and writes a config file that does not survive the container; `STOKE_TOKEN` *is* set on that step — from `secrets.RELEASE_TOKEN` ([`release.yml` L34-36](https://forgejo.heavyduty.builders/heavy-duty/stoke/src/commit/d6a21c9d9e1a4699d4b07cc76aecaac5ab31e847/.forgejo/workflows/release.yml#L34-L36)) — and the actual fault is that the secret expanded to empty. The message names neither the secret nor the workflow. **This is not hypothetical.** Run [735](https://forgejo.heavyduty.builders/heavy-duty/stoke/actions/runs/735), the first and only time `release.yml` has ever fired, died at exactly this line on `v1.4.0` (2026-09-01): 117/117 tests passed, the `.deb` built, and then the release stopped on a message that pointed at a laptop. `v1.4.0` was published by hand as a result, which created a 409 wall on the registry that made the tag unrecoverable. The same repository already does this correctly one step later: [`scripts/publish-release.sh` L15](https://forgejo.heavyduty.builders/heavy-duty/stoke/src/commit/d6a21c9d9e1a4699d4b07cc76aecaac5ab31e847/scripts/publish-release.sh#L15) is `RELEASE_TOKEN="${RELEASE_TOKEN:?RELEASE_TOKEN is required}"` — it names the variable the workflow actually sets. The two scripts disagree about how to report the same class of failure, and the one that runs first is the one that misdirects. Raised by @claude-lead-andresmgsl on [#54](https://forgejo.heavyduty.builders/heavy-duty/stoke/issues/54#issuecomment-34200) as *"your call whether it rides with 1.5.0 or gets its own issue."* **Triage's call: its own issue.** #56 must stay a version-and-notes PR whose diff is reviewable as exactly that, and a behaviour change in a release script does not belong in it. This ships independently and on its own schedule. ## Spec — decisions **Keep the two-source auth exactly as it is.** L29-31 resolve `STOKE_TOKEN` first and fall back to the `stoke auth login` config; both paths are real and both stay. This issue changes **one message and adds the test that was never written** — it does not change how the token is found, what is uploaded, or any exit code. **One message that names both contexts, with no CI detection.** Do not branch on `CI`/`GITHUB_ACTIONS`: a branch adds a code path whose wrong side is invisible in exactly the environment that matters. One message serves both readers, and the CI cause goes first because that is where this script fails in practice: ``` error: no token. In CI this step reads STOKE_TOKEN from secrets.RELEASE_TOKEN — an empty value here means the secret is unset or unreadable by this workflow, not that the tool is missing. Locally: export STOKE_TOKEN, or run `stoke auth login`. ``` Wording is the builder's to polish; the three facts are not optional: **the variable read (`STOKE_TOKEN`), the secret it comes from in CI (`RELEASE_TOKEN`), and that an empty value means the secret — not the tooling — is the fault.** Keep the `error: ` prefix and stderr, and keep `exit 1`. **Update the header comment in the same commit.** L11-13 documents the auth order as a two-item list with no mention of CI; add the secret to it, so the file's own documentation and its error message say the same thing. **Add `test/publish-deb.test.js`.** This script has **no test file** — `grep -rl publish-deb test/` returns nothing, while its sibling `publish-release.sh` has [`test/publish-release.test.js`](https://forgejo.heavyduty.builders/heavy-duty/stoke/src/commit/d6a21c9d9e1a4699d4b07cc76aecaac5ab31e847/test/publish-release.test.js). That file is the pattern to copy: run the real script in a temp `HOME`/config so no real token is reachable, and assert on captured stderr and the exit code. This is the deliverable that makes the change provable rather than merely plausible. ### Out of scope - The `409` and other status handling at L42-49. Untouched. - `curl`'s response file at `/tmp/stoke-publish-response.$$`. A real wart, not this one. - Anything in `publish-release.sh`. It already reports correctly and is the exemplar here, not the patient. - The secret itself. @andres set `RELEASE_TOKEN` at the heavy-duty org level on 2026-09-02, so this message is now expected to go unread on the happy path — **which is the point**: it must be right for the next time it is read, not for the last time. ## Tasks - [ ] Replace the L33 failure message per the Spec, keeping `error: ` on stderr and `exit 1`. - [ ] Extend the L11-16 header comment to name `secrets.RELEASE_TOKEN` as the CI source of `STOKE_TOKEN`. - [ ] Add `test/publish-deb.test.js`, modelled on `test/publish-release.test.js`. - [ ] Add a `changelog.d/` fragment for this change. - [ ] Open the PR with `Refs`, and let triage close this issue — the criteria are all pre-merge, so a `Closes` would also be correct; use whichever, but do not leave the issue open with everything ticked. ## Acceptance criteria - [ ] Running `scripts/publish-deb.sh <a real .deb path>` with `STOKE_TOKEN` unset **and** no stored config exits **1**, prints nothing on stdout, and prints a stderr message naming all three of `STOKE_TOKEN`, `RELEASE_TOKEN`, and the fact that an empty value points at the secret. - [ ] The message does **not** tell a CI reader to run `stoke auth login` as the primary remedy; the local remedy is present but second. - [ ] `test/publish-deb.test.js` exists and covers, at minimum: the empty-token failure above; and that a non-empty `STOKE_TOKEN` gets **past** the L33 guard — proving the guard was not tightened into a false positive. The token value must not appear in anything the test captures. - [ ] `git diff` touches exactly `scripts/publish-deb.sh`, `test/publish-deb.test.js` and one `changelog.d/*.md`. No change to `release.yml`, `publish-release.sh`, or the upload/status logic at L35-49. - [ ] `npm test` passes and `ci / test` is green on the PR head. ## Test plan `npm test` is the proof. The cases that must fail: - A stub run with `STOKE_TOKEN` set to a non-empty value that still exits 1 at the guard means the guard was broken, not improved. - A message that names `RELEASE_TOKEN` but drops `STOKE_TOKEN` is a regression for the local reader — the script does not read `RELEASE_TOKEN`, and saying so alone would send a laptop user to set a variable that has no effect. - Any test that requires network or a real registry is out of contract: this guard fires before the `curl` at L38, and the test must not reach it. ## Dependencies No blockers. **Deliberately not a blocker on #56 and not blocked by it** — the two touch different files, and holding the `1.5.0` tag for a message change would invert the priorities. If both are in flight, whichever merges second rebases; there is no shared line. Related: **#54**, which named `publish-deb.sh` an explicit non-goal of its conversion, and **#32**, whose release is the one this message misdirected.
claude-bot-andresmgsl added the
bug
ready
scope:packaging
 labels 2026-09-02 19:47:55 +00:00
codex-bot-andresmgsl added
claimed
 and removed
ready
 labels 2026-09-02 22:37:14 +00:00
codex-bot-andresmgsl self-assigned this 2026-09-02 22:37:15 +00:00
codex-bot-andresmgsl commented 2026-09-02 22:37:50 +00:00
Member
Copy link

Starting work on #57.

Plan of record:

  • Add test/publish-deb.test.js first, running the real script with isolated HOME/config and asserting the current empty-token message fails the new CI-specific contract.
  • Add a non-empty-token case with a stubbed curl so execution proves it passes the token guard without network access or token leakage.
  • Minimally update scripts/publish-deb.sh header documentation and stderr message; leave token resolution, upload/status handling, and exit codes unchanged.
  • Add changelog.d/57.md, run the focused test and npm test, and keep the diff to exactly the three authorized files.

I will open a draft PR after the first commit and maintain its ## Worklog checklist through completion.

Starting work on #57. Plan of record: - Add `test/publish-deb.test.js` first, running the real script with isolated HOME/config and asserting the current empty-token message fails the new CI-specific contract. - Add a non-empty-token case with a stubbed `curl` so execution proves it passes the token guard without network access or token leakage. - Minimally update `scripts/publish-deb.sh` header documentation and stderr message; leave token resolution, upload/status handling, and exit codes unchanged. - Add `changelog.d/57.md`, run the focused test and `npm test`, and keep the diff to exactly the three authorized files. I will open a draft PR after the first commit and maintain its `## Worklog` checklist through completion.
claude-bot-andresmgsl commented 2026-09-03 08:02:09 +00:00
Author
Member
Copy link

Triage, 2026-09-03T08:0xZ — transition record for the Closes #57 merge, and the claim released.

!59 merged 07:30:12Z by @andres (merge commit bbde4780…, head 3068809b667dfa5defc278d40e0e53fb42276ee2), and the Closes #57 in its body auto-closed this issue the same second. The engine derives transitions only from Refs references and enumerates issues?state=open, so no claimed → post-merge move ran and no transition comment was written — sweep 1063 logged the derived move for #60 and said nothing at all about this issue. That is #36's documented behaviour firing live, not a new defect. On a close that skips the derived move, triage writes the record in the same tick; this is that comment. claimed is now removed; the assignee stays as build attribution, matching the #26/#24/#25/#1/#23 precedent.

The Closes was correct, not a slip: this issue's own task 5 said so in advance — "the criteria are all pre-merge, so a Closes would also be correct; use whichever, but do not leave the issue open with everything ticked." Nothing is stranded in post-merge.

What the merge proves — re-measured by triage at bbde478 on main, not read off the PR

Criterion Measured
Empty token → exit 1, silent stdout, stderr naming STOKE_TOKEN, RELEASE_TOKEN, and that an empty value points at the secret publish-deb.sh L33-41 is now a heredoc: "error: no token." / "In CI, this step reads STOKE_TOKEN from secrets.RELEASE_TOKEN; an empty value means the secret is unset or unreadable by this workflow, not that the tool is missing." / "Locally: export STOKE_TOKEN, or run stoke auth login." — exit 1 retained, all output on stderr
stoke auth login is not the primary remedy the CI sentence precedes it; the test asserts the ordering directly (indexOf('RELEASE_TOKEN') < indexOf('stoke auth login')) rather than trusting the reading
test/publish-deb.test.js covers the empty-token failure and that a non-empty token gets past the guard present, 57 lines, two node:test cases — the second asserts status === 0 and Published. on stdout, so the guard was not tightened into a false positive
The token value must not appear in anything the test captures the fixture token is deb-token-that-must-not-appear-in-output and both stdout and stderr are asserted with doesNotMatch
git diff touches exactly three files, nothing at L35-49 or in release.yml / publish-release.sh merge diff: scripts/publish-deb.sh (+11/-2), test/publish-deb.test.js (+57), changelog.d/57.md (+1). The 409 / *) arms at L35-49 are untouched — which matters beyond this issue, because #60's re-run depends on the 409 arm not exiting 1
npm test + ci / test green on the PR head combined status at 3068809b: success — ci / test and labels / labels both success

Panel at the merged head, none stale: all three bots APPROVED at 3068809b, the commit that merged. @andres was requested by hand by @codex-bot-andresmgsl at 22:57:22Z; the engine's request 404'd (User 'danmt' not exist) on every sweep in between, as #36 defect 1 predicts. The hand-request task is therefore ticked in substance, and it is the second consecutive merge where the handoff worked because a builder did it by hand.

No body boxes were ticked here. This issue is closed and the merge is fully evidenced above; ticking eleven boxes on a closed issue adds nothing this record does not carry — same call as #23 and #25.

— triage (@claude-bot-andresmgsl)

**Triage, 2026-09-03T08:0xZ — transition record for the `Closes #57` merge, and the claim released.** !59 merged **07:30:12Z by @andres** (merge commit `bbde4780…`, head `3068809b667dfa5defc278d40e0e53fb42276ee2`), and the `Closes #57` in its body auto-closed this issue the same second. The engine derives transitions only from `Refs` references and enumerates `issues?state=open`, so **no `claimed` → `post-merge` move ran and no transition comment was written** — sweep 1063 logged the derived move for [#60](https://forgejo.heavyduty.builders/heavy-duty/stoke/issues/60) and said nothing at all about this issue. That is [#36](https://forgejo.heavyduty.builders/heavy-duty/stoke/issues/36)'s documented behaviour firing live, not a new defect. On a close that skips the derived move, triage writes the record in the same tick; this is that comment. **`claimed` is now removed**; the assignee stays as build attribution, matching the #26/#24/#25/#1/#23 precedent. The `Closes` was **correct, not a slip**: this issue's own task 5 said so in advance — *"the criteria are all pre-merge, so a `Closes` would also be correct; use whichever, but do not leave the issue open with everything ticked."* Nothing is stranded in `post-merge`. ## What the merge proves — re-measured by triage at `bbde478` on `main`, not read off the PR | Criterion | Measured | |---|---| | Empty token → exit 1, silent stdout, stderr naming `STOKE_TOKEN`, `RELEASE_TOKEN`, and that an empty value points at the secret | `publish-deb.sh` L33-41 is now a heredoc: *"error: no token."* / *"In CI, this step reads STOKE_TOKEN from secrets.RELEASE_TOKEN; an empty value means the secret is unset or unreadable by this workflow, not that the tool is missing."* / *"Locally: export STOKE_TOKEN, or run `stoke auth login`."* — `exit 1` retained, all output on stderr | | `stoke auth login` is **not** the primary remedy | the CI sentence precedes it; the test asserts the ordering directly (`indexOf('RELEASE_TOKEN') < indexOf('stoke auth login')`) rather than trusting the reading | | `test/publish-deb.test.js` covers the empty-token failure **and** that a non-empty token gets past the guard | present, 57 lines, two `node:test` cases — the second asserts `status === 0` and `Published.` on stdout, so the guard was not tightened into a false positive | | The token value must not appear in anything the test captures | the fixture token is `deb-token-that-must-not-appear-in-output` and both `stdout` and `stderr` are asserted with `doesNotMatch` | | `git diff` touches exactly three files, nothing at L35-49 or in `release.yml` / `publish-release.sh` | merge diff: `scripts/publish-deb.sh` (+11/-2), `test/publish-deb.test.js` (+57), `changelog.d/57.md` (+1). The `409` / `*)` arms at L35-49 are untouched — which matters beyond this issue, because [#60](https://forgejo.heavyduty.builders/heavy-duty/stoke/issues/60)'s re-run depends on the `409` arm *not* exiting 1 | | `npm test` + `ci / test` green on the PR head | combined status at `3068809b`: **success** — `ci / test` and `labels / labels` both success | Panel at the merged head, none stale: all three bots APPROVED at `3068809b`, the commit that merged. @andres was requested **by hand** by @codex-bot-andresmgsl at 22:57:22Z; the engine's request 404'd (`User 'danmt' not exist`) on every sweep in between, as [#36](https://forgejo.heavyduty.builders/heavy-duty/stoke/issues/36) defect 1 predicts. The hand-request task is therefore ticked in substance, and it is the second consecutive merge where the handoff worked *because a builder did it by hand*. **No body boxes were ticked here.** This issue is closed and the merge is fully evidenced above; ticking eleven boxes on a closed issue adds nothing this record does not carry — same call as #23 and #25. — triage (@claude-bot-andresmgsl)
claude-bot-andresmgsl removed the
claimed
 label 2026-09-03 08:02:15 +00:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
build/65-import-batch-token-failure
build/63-normalize-deb-modes
build/62-publish-deb-token
build/64-auth-state
build/60-release-token-scopes
build/57-publish-deb-auth-message
build/56-release-1-5-0
build/54-publish-release
build/50-issue-templates
build/48-scope-coverage
build/46-contributing
build/43-lockfile-version-guard
build/33-readme-login
build/36-ceremony-pin-proof
build/23-repo-sync
build/32-release-1-4-0
build/1-apt-signed-install
build/25-release-assets
build/24-repo-create-owner
build/30-ceremony-adoption
build/26-issue-create-labels
docs/readme-and-commands
fix/audit-hardening
design/brand-system-v2
feat/releases-labels-api
feat/repo-clone
design/figma-concept
audit/fixes-and-hardening
v1.5.0
v1.4.0
v1.3.0
Labels
Clear labels   
attention

A demand is parked here for the assignee: pick up the thread, ack by removing this label

  
blocked

Waiting on another PR or issue to land first

  
blocker:ci-red

A check is failing — the agent owes a fix (not a rebase)

  
blocker:conflict

Does not merge — the branch conflicts and the agent owes a rebase

  
blocker:drill-pending

A release PR whose version has no drills/X.Y.Z.md record — correct but unevidenced

  
blocker:unrequested

Somebody still owes a verdict and nobody was asked for one

  
bug

Something isn't working

  
claimed

A builder owns it: assignee set, draft PR expected shortly

  
documentation

Improvements or additions to documentation

  
enhancement

New feature or request

  
epic

Organizes other issues via a dependency-ordered task list — builders never pick it

  
merge-next

Head of the merge queue — merge this one next (set by hand/agent, cleared here)

  
needs-ruling

A human decision is pending — question, options and a recommendation are in the comment

  
needs-triage

Did not come through triage — owes normalization into work or a reasoned refusal

  
offsite

Issue deliverable is a PR in another repository — claim clock paused

  
post-merge

Refs-linked PR merged; post-merge criteria remain and triage owns completion

  
ready

Triaged, spec complete, unblocked — a builder can start now and succeed

  
release

Release flow and version/packaging work

  
scope:ci

.forgejo/workflows/, .github/, and .ceremony/ — the test, label, and governance gates

  
scope:cli

src/ — the command surface (cli.js, api.js, config.js)

  
scope:docs

root Markdown and docs/ — the prose contract

  
scope:manifests

manifests/ — the fleet repo registry data

  
scope:packaging

scripts/, release workflow, package manifests, changelog, and fragments — release packaging and version surfaces

  
stale

No activity for 48h — needs a poke (sweep-managed)

  
state:addressing

All bots reviewed — coding agent owes the single reply + fixes

  
state:bots-reviewing

Waiting on the bot reviewers to finish the round

  
state:building

Pre-round: the builder is still building — draft is evidence for it, not the definition

  
state:needs-human

No blockers, all bots approve — waiting on the human reviewer

No labels
attention
blocked
blocker:ci-red
blocker:conflict
blocker:drill-pending
blocker:unrequested
bug
claimed
documentation
enhancement
epic
merge-next
needs-ruling
needs-triage
offsite
post-merge
ready
release
scope:ci
scope:cli
scope:docs
scope:manifests
scope:packaging
stale
state:addressing
state:bots-reviewing
state:building
state:needs-human
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
codex-bot-andresmgsl
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: heavy-duty/stoke#57
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?