sneak/vaultik
1
0
Fork 0
Code Issues 18 Pull Requests 4 Actions Packages Projects Releases Wiki Activity

Compare commits

base: sneak/vaultik:d809990832e046f493c6a3fac0eae56ef8056684
Branches Tags
sneak/vaultik:main sneak/vaultik:next sneak/vaultik:issue-124-restore-another-machine sneak/vaultik:issue-66-storage-tests sneak/vaultik:issue-112-json-decouple-quiet sneak/vaultik:feature/daemon-mode
..
compare: sneak/vaultik:f3dc6e78a77e4a0986a33e91c846b05327dc2741
Branches Tags
sneak/vaultik:next sneak/vaultik:issue-124-restore-another-machine sneak/vaultik:issue-66-storage-tests sneak/vaultik:issue-112-json-decouple-quiet sneak/vaultik:main sneak/vaultik:feature/daemon-mode
3 Commits
d809990832 .. f3dc6e78a7
Author SHA1 Message Date
clawbot f3dc6e78a7 Hash-verify the Go toolchain in the release workflow (closes #105)
check / check (pull_request) Failing after 1s
Details 
The release workflow installed Go via actions/setup-go, which pins the
action but not the toolchain tarball it downloads at runtime -- the
compiler that produces the published binaries was the last external
input in the release path verified against nothing in the repo, against
REPO_POLICIES.md's hash-pin rule.

New script/install-go, modelled on script/install-goreleaser, downloads
the exact go.dev archive for go.mod's `go` directive and refuses it
unless its sha256 matches a value committed in the script. release.yml
calls it instead of setup-go and sets GOTOOLCHAIN=local so that exact
compiler builds the release. The version is not duplicated: go.mod owns
it and install-go fails when its committed GO_VERSION disagrees, so
bumping Go edits go.mod, the checksum, and the Dockerfile golang digest
together.

Model: opus-4-8
 2026-09-21 16:59:31 +00:00
clawbot d2a0510cb4 Trigger CI on next, not only main (closes #122)
check / check (pull_request) Failing after 0s
Details
check / check (push) Successful in 3m33s
Details 
`check.yml` ran only on push to `main` and on pull requests against `main`. Every unit is a PR based on `next`, and `next` is pushed on each squash-merge, so no unit PR and no push to `next` ever ran CI; a broken `next` would first surface on the milestone PR. `next` is added to both branch lists; nothing else in the workflow changes. The README Entrypoints section now says where CI runs.

Disclosure: the CI run on the PR itself fired (the proof the trigger works) but was red because the runner had no disk space left before any check step ran; the local gate was green.

Model: opus-4-8 (implementation and review)
model: claude-fable-5
 2026-09-21 14:55:59 +02:00
clawbot 583f65040a Correct --cron flag help to name warnings as unsuppressed (closes #87)
check / check (pull_request) Failing after 0s
Details 
`--cron` sets the UI quiet, but `Warningf` and `Errorf` are unconditional, and the snapshot summary is routed through `Warningf` on purpose so cron delivers something on a successful run. The help string said `silent unless error`, so a user could read normal cron output as a failure. It now says `silent unless warning or error`, matching the README. String only; no behavior change.

Model: opus-4-8 (implementation and review)
model: claude-fable-5
 2026-09-21 14:55:45 +02:00
4 changed files with 11 additions and 3 deletions
Expand all files Collapse all files
.gitea/workflows/check.yml
+2 -2
View File
@@ -1,9 +1,9 @@
name: check name: check
on: on:
push: push:
branches: [main] branches: [main, next]
pull_request: pull_request:
branches: [main] branches: [main, next]
jobs: jobs:
check: check:
runs-on: ubuntu-latest runs-on: ubuntu-latest
README.md
+2
View File
@@ -724,6 +724,8 @@ them. We provide:
then the product image). Either failing fails the script. It runs the then the product image). Either failing fails the script. It runs the
checks in the same containers CI does, from a clean copy of the tree, checks in the same containers CI does, from a clean copy of the tree,
so it also catches anything that depends on host state. so it also catches anything that depends on host state.
`.gitea/workflows/check.yml` runs it on every push to `main` and
`next` and on every pull request against either.
It passes a fresh `--build-arg CHECK_EPOCH` to each build, unique per It passes a fresh `--build-arg CHECK_EPOCH` to each build, unique per
invocation, which both files declare immediately above their check invocation, which both files declare immediately above their check
TODO.md
+6
View File
@@ -25,6 +25,12 @@ release" is exactly the contradiction
# Completed Steps # Completed Steps
- 2026-09-21: Made `.gitea/workflows/check.yml` run on pushes to `main`
and `next` and on pull requests against either, so unit PRs (whose
base is `next`) and `next` itself get a CI run instead of relying on a
local `make check`
([issue #122](https://git.eeqj.de/sneak/vaultik/issues/122)).
- 2026-09-21: Hash-verified the Go toolchain in the release workflow - 2026-09-21: Hash-verified the Go toolchain in the release workflow
([issue #105](https://git.eeqj.de/sneak/vaultik/issues/105)). New ([issue #105](https://git.eeqj.de/sneak/vaultik/issues/105)). New
`script/install-go` downloads the exact `go.dev` archive for `go.mod`'s `script/install-go` downloads the exact `go.dev` archive for `go.mod`'s
internal/cli/snapshot.go
+1 -1
View File
@@ -135,7 +135,7 @@ specifying a path using --config or by setting VAULTIK_CONFIG to a path.`,
} }
cmd.Flags().BoolVar(&opts.Cron, "cron", false, cmd.Flags().BoolVar(&opts.Cron, "cron", false,
"Run in cron mode (silent unless error)") "Run in cron mode (silent unless warning or error)")
cmd.Flags().BoolVar(&opts.Prune, "prune", false, cmd.Flags().BoolVar(&opts.Prune, "prune", false,
"After backup, drop older snapshots of the same name and remove "+ "After backup, drop older snapshots of the same name and remove "+
"orphaned blobs") "orphaned blobs")