chadtmiller.com/knotless

Switch repository

Loading…

git that lives in your Atmosphere account

knotless 0.13.0 Latest 2 packages, 1 image

Release 0.5.0

Merged chadtmiller.com asked to merge into main from chadtmiller.com/knotless:release/0.5.0

.changeset/ejected-logs.mddeleted+0−7

.changeset/org-space-type.mddeleted+0−7

.changeset/shared-steps.mddeleted+0−7

.changeset/show-mentions.mddeleted+0−7

.changeset/space-scopes.mddeleted+0−7

.changeset/status-disk.mddeleted+0−7

.changeset/step-on.mddeleted+0−7

.changeset/themes-of-your-own.mddeleted+0−9

Cargo.lock+6−6

Cargo.toml+1−1

CHANGELOG.md+40−0

		@@ -1,7 +0,0 @@
		`---`
		`default: patch`
		`---`

		# `knotless show` names the command that reads an ejected pull's logs

		A pull the merge queue ejected as its checks failed shows `logs: knotless checks <url> --pull <pull> --log`, or `--queue <branch>` for a batch, after where it stands. The runner no longer writes that command into the reason it records, which the web pages show beside links to the checks that failed.

		@@ -1,7 +0,0 @@
		`---`
		`default: patch`
		`---`

		# An organization's space has a type of its own, `dev.knotless.orgSpace`

		An organization keeps its invitations and hidden members in a space of the type `dev.knotless.orgSpace`, which has its own lexicon, so that a login can name it. Its gateway moves an organization out of its old space, of the type `dev.knotless.org`, as it starts and as the organization next changes, keeping each member where they stood. A hidden member's record of joining stays in the old space, and counts, until they join again: `knotless org join <org> --hidden` moves it.

		@@ -1,7 +0,0 @@
		`---`
		`default: minor`
		`---`

		`# A workflow step can use a step another repository shares`

		A step with `uses: <owner>/<repo>/<step>@<version>` runs the steps of `.knotless/steps/<step>.yml` in that repository, at the commit `.knotless/uses.lock` pins it to, with the inputs `with` gives, only the secrets the step passes it, and its own repository checked out beside the checkout as `KNOTLESS_STEP_DIR`. A step file can use shared steps of its own. Release a step with `knotless publish <url> @step/<step> <version> .knotless/steps/<step>.yml --commit <sha>`, and pin the ones a checkout uses with `knotless uses update`. Each step is now given its secrets as it starts, rather than the container holding them all.

		@@ -1,7 +0,0 @@
		`---`
		`default: minor`
		`---`

		# `show` lists the pulls that mention an issue

		`knotless show` on an issue prints `mentioned in <pull>` for each pull on the repository whose title or body names it, oldest first, ending `, to close it` where the pull names it after a closing keyword. MCP's `show_item` gives the same as `mentionedBy`.

		@@ -1,7 +0,0 @@
		`---`
		`default: minor`
		`---`

		`# A login and a gateway's grant name knotless's own space types`

		`knotless login` asks for `space:dev.knotless.space` and `space:dev.knotless.orgSpace`, each with the collections knotless writes there, in place of every space of every app (`space:*`); `knotless delegate` asks the same of a gateway's grant. A login or grant from before still works, and is asked for again as any older one is.

		@@ -1,9 +0,0 @@
		`---`
		`default: minor`
		`---`

		`# Themes of your own`

		The pages' Appearance settings make a theme of your own colours, checked as you choose them for text that reads on what it is drawn on, and publish it as a `dev.knotless.theme` record for anyone to choose from Appearance. Choosing one copies its colours into your preferences, so its author changing or deleting it later leaves your pages as they are. Logging in again asks to write `dev.knotless.theme` records.

		The command line does the same: `knotless theme check`, `publish`, `use` and `delete`, and `knotless themes` to find them; and over MCP, the `theme` and `list_themes` tools. A palette is held to the same contrast wherever it is made.

		@@ -3,7 +3,7 @@ members = ["crates/knotless", "crates/knotless-serve", "crates/knotless-mcp", "c
		`resolver = "3"`

		`[workspace.package]`
		`version = "0.4.0"`
		`version = "0.5.0"`
		`edition = "2024"`
		`license = "MIT OR Apache-2.0"`
		`rust-version = "1.89"`

		@@ -1,7 +0,0 @@
		`---`
		`default: patch`
		`---`

		# `knotless status` shows the server's disk

		`knotless status` adds a `disk` line: how much room is left on the disk a knotless-serve keeps its mirrors on. Under 15% free the disk shows as `low` among the problems, and under 5% the server counts as unhealthy.

		@@ -1,7 +0,0 @@
		`---`
		`default: minor`
		`---`

		`# A workflow step can run only at some refs`

		A step with `on: {refs: [refs/heads/main, refs/tags/*]}` runs only at a push to, or a run asked for at, a ref those patterns match, as `on.push.refs` are matched; anywhere else it passes unrun, listed `skipped`, its log saying why. A pull's run and a merge-queue batch's run are at no ref, so such a step runs in neither. On a step with `uses`, its `on` holds for every step the shared step comes to, beside their own.