clawbot
ed95e66f7d
Adopt the standard tooling: a Makefile of thin shims over a full scripts-to-rule-them-all `script/` set, the canonical `.golangci.yml` vendored byte-identical from `sneak/prompts`, docker-only linting via `Dockerfile.lint`, a `Dockerfile` and Gitea workflow that gate every push, and prettier/editorconfig/dockerignore config. `make build` pointed at a `cmd/dcfinfo` that is not in the tree and could never have succeeded; this repo is a library, so `build` is now the compile check over every package. Clear the 57 findings the canonical linter config reports on `pkg/dcf`. Two were real: `findDCFMountPoints` checked a never-assigned `erro` instead of the error from `findAllMountPoints`, discarding it, and `privatePath` was computed twice so the first computation was dead. Mountpoint selection otherwise behaves exactly as before; the defects that survive are filed as issue #6, not fixed here. Rename `DCFStore` to `Store` and `DCFObject` to `Object` (with its `DCFStoreRoot` field to `StoreRoot`), which revive's stutter rule requires and which the `fs.FS` rework in issue #4 will build on. Replace the placeholder test with tests over the exported surface. The filesystem walk stays uncovered: it is reachable only through `GetDCFStores`, which needs real mounted media. README keeps its content, reorganised into the required sections and gaining Entrypoints. (closes #1)
72 lines
2.8 KiB
Bash
Executable File
72 lines
2.8 KiB
Bash
Executable File
#!/bin/sh
|
|
# script/lint: run the linter. golangci-lint is never installed locally: it
|
|
# runs via docker only, one way, everywhere.
|
|
#
|
|
# Traps, each of which yields a green run over an unlinted or partly linted
|
|
# tree:
|
|
#
|
|
# 1. A bare `docker build -f Dockerfile.lint .` serves the lint layer from
|
|
# cache on an unchanged tree and exits 0 having linted nothing, and
|
|
# BuildKit ignores a --no-cache-filter whose stage name matches
|
|
# nothing, restoring that no-op after a rename. So the run is not
|
|
# trusted: script/assert-step-ran requires the log to show the lint
|
|
# step executing and golangci-lint's own success line coming out of
|
|
# it. A cached or absent step fails that.
|
|
#
|
|
# 2. .dockerignore decides what reaches the container, and only what
|
|
# reaches it is linted, so excluding a Go file drops it from the lint
|
|
# with the linter still reporting `0 issues.` over what it was
|
|
# handed. So the context is not trusted either: the lint stage
|
|
# inventories the sources that reached it, and
|
|
# script/assert-context-complete compares that against the git index,
|
|
# which .dockerignore cannot touch. Never exclude Go sources,
|
|
# go.mod/go.sum or .golangci.yml — and now nothing silently does.
|
|
set -eu
|
|
|
|
SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd -P)"
|
|
ROOT="$(cd "$SCRIPT_DIR/.." && pwd -P)"
|
|
|
|
dockerfile=Dockerfile.lint
|
|
|
|
# Must match the stage name in Dockerfile.lint.
|
|
stage=lint
|
|
|
|
main() {
|
|
cd "$ROOT"
|
|
|
|
tmp="$(mktemp -d "${TMPDIR:-/tmp}/$("$SCRIPT_DIR/projectname")-lint.XXXXXX")"
|
|
trap 'rm -rf "$tmp"' EXIT INT TERM
|
|
|
|
# No --target: whatever stage is last is the one BuildKit builds, and
|
|
# the assertion below is what decides whether the linter was in it.
|
|
# --progress=plain is load-bearing — the tty renderer discards all but
|
|
# the tail of a step's output. The exit status travels through a file
|
|
# because a pipeline's status is the last command's; `set +e` is what
|
|
# lets the recording line run at all, since errexit would otherwise
|
|
# abandon the subshell on a failing build. A missing file reads as
|
|
# failure.
|
|
(
|
|
set +e
|
|
docker build \
|
|
--progress=plain \
|
|
--no-cache-filter="$stage" \
|
|
--output=type=cacheonly \
|
|
-f "$dockerfile" . 2>&1
|
|
echo "$?" >"$tmp/status"
|
|
) | tee "$tmp/build.log"
|
|
|
|
status="$(cat "$tmp/status" 2>/dev/null || echo 1)"
|
|
[ "${status:-1}" -eq 0 ] || exit "${status:-1}"
|
|
|
|
script/assert-step-ran "$tmp/build.log" "$stage" \
|
|
'^RUN golangci-lint run' '^0 issues[.]$' 'the linter'
|
|
|
|
# That the linter ran says nothing about what it was given. The
|
|
# expectation comes from git and the evidence from the build, which
|
|
# is the only reason comparing them means anything.
|
|
script/repo-source-manifest >"$tmp/expected"
|
|
script/assert-context-complete "$tmp/build.log" "$stage" "$tmp/expected"
|
|
}
|
|
|
|
main "$@"
|