vole

Clone

Read only, no credentials:

https://rodent.software/git/vole.git

Write over SSH with a registered key:

git clone ssh://git@0.0.0.0:2222/vole.git

A free and open-source forge that lives in your Git repo.

Phase 2: issue CLI, cross-references, backlinks, filter and search

c1e3e3ca696c2bae8692775977fdae21ed50bc4a · Keenan Nemetz · 18d ago · parent 37c01e5a

Phase 2: issue CLI, cross-references, backlinks, filter and search

The issue format needed no client, and still does not: every one of these is
sugar over files anyone can write. The CLI exists so the common case is not
ceremony.

- `vole issue new|comment|close|reopen|list|show` works on the clone in the
  current directory. It fetches the issues branch first so its commit is a
  fast-forward the server will accept, validates locally so a malformed issue
  never costs a round trip, then pushes. Writing goes through gitx.CommitFiles,
  the shared CAS path, so a concurrent author's commit cannot be clobbered.
- Ids may be abbreviated. `list` prints eight characters, so every id-taking
  command resolves prefixes and refuses an ambiguous one with the candidates
  listed. This was a real bug: list printed short ids while comment and close
  demanded the full ULID, so copying the id from the CLI's own output failed.
  The integration test now drives the CLI with a prefix.
- `#<ulid>` in an issue body or comment renders as a link. Rewriting happens on
  the markdown source, skipping fenced blocks so a reference inside a code
  sample stays literal; a test asserts both halves.
- Backlinks: commits whose message mentions an id are listed on the issue, found
  with `git log --grep`. git does the search, so there is no second index.
- Filtering and search on the list page: state, label, and a LIKE over title and
  body, backed by an `issue_labels` table and an indexed `body` column.

Notifications are deliberately not built. The web is read-only and has no user
identity, so "in-app" has nobody to notify and email would need subscriptions,
which need a store. The honest fit is a per-repo Atom feed when someone wants
one; the roadmap says so rather than leaving a phantom item.

Verified by hand with a clone and a key: filed an issue, listed it, commented
using the short id, closed it, confirmed the web showed the closed state, the
rendered comment and the label filter, and that an ambiguous prefix is refused.

README.md +16−2

@@ -90,8 +90,22 @@ git add -A && git commit -m "issue: docs page blank" && git push origin issues
	90	90	```
	91	91
	92	92	The id must be a ULID (26 characters, Crockford base32 — uppercase, no `I`, `L`,
	93		`O` or `U`). A UUID is not one and will be rejected. Any ULID generator works, or
	94		`vole issue new` once that lands.
		93	`O` or `U`). A UUID is not one and will be rejected.
		94
		95	Or use the CLI, which is the same thing with the paperwork done:
		96
		97	```sh
		98	vole issue new -title "Nothing renders on the docs page" -body "Steps..." -label bug
		99	vole issue comment 01M5JR2JK29KKMAA1T9MDNTPBP -body "Also affects search"
		100	vole issue close 01M5JR2JK29KKMAA1T9MDNTPBP
		101	vole issue list -state open -label bug
		102	vole issue show 01M5JR2JK29KKMAA1T9MDNTPBP # a prefix is enough
		103	```
		104
		105	The CLI writes the files, commits to the `issues` branch, validates locally and
		106	pushes. `#<ulid>` in a body links to that issue, and commits whose message
		107	mentions an id are listed as backlinks on the issue. The list page filters by
		108	state and label and searches titles and bodies.
	95	109
	96	110	A comment is `issues/<id>/comments/<ulid>.md` with `author` and `created`
	97	111	frontmatter. Closing an issue is editing `state` to `closed`. The push is