keb
b773dfe296
Fixes: - A newer release shows in the status pane (`↑ v0.2.0`), not the footer. - The account in `lazysecrets list` is plain `Azure` with one az account; `Azure:<user>/<tenant>` only with several. - Sharing lists subscription, workspace and scope links, and opening takes Azure portal links. - `--timeout` and `--clipboard-clear` are documented, next to their config keys. - `--kind`'s description reads, and says `vault` covers scopes and repo files. - `lazysecrets -h` lists `list`'s `--stars`, `--notes`, `--recent` and `--expiry`. - README typos; "Supported platforms" is "Sources". Trimmed: - An option is documented on its topic's page; config.md's example keeps the general ones and links the rest. - The fzf picker lives in docs/integration.md; the README keeps a link and the screenshot. - The clipboard clear, reveal timeout, per-account stars, Azure's "no extra requests" and `open --action` are each said once. - The status pane's contents are a list; build sizes and PR-title spellings are gone from development.md. Reviewed-on: #74 Co-authored-by: Karl-Einar Bergstrøm <karl-einarb@outlook.com>
2.8 KiB
Development
go run ./cmd/lazysecrets
go run ./cmd/lazysecrets --demo # built-in sample data, no Azure needed
go test ./...
go test ./internal/ui/app -run TestGolden -update # after intentional UI changes
In --demo, sharing env files works end to end: S → f on a demo
repo, pick kv-shared-prod / env-share (the second account's) as the
key, then paste the link back. The demo repos aren't on disk, so opening
asks where to save, as for a repo you haven't cloned.
A stripped binary is a third smaller:
go build -trimpath -ldflags "-s -w" -o lazysecrets ./cmd/lazysecrets
Development builds show dev-<commit> as their version (-dirty with
uncommitted changes); go install …@v0.2.0 shows the tag, releases the
version they were built for.
How changes land
Pull requests into main are squash-merged, so each is one commit titled
like the PR. The title is a conventional commit
subject, checked by pr-title.yml:
| Type | For | In the changelog |
|---|---|---|
feat |
a new feature | Added |
perf |
faster or smaller, same behaviour | Changed |
fix |
a bug fix | Fixed |
refactor, docs, test, ci, chore, build, style, revert |
everything users don't need to hear about | no |
feat!: marks a breaking change, feat(scope): names a part.
[skip changelog] in the description leaves a pull request out.
CI (ci.yml) runs gofmt, vet, staticcheck, the tests and a build for each
platform on pull requests into main. main is protected: a pull request
merges only when it's up to date with main (Gitea's "Update branch"
button, or a rebase, then CI again), so what lands on main is exactly
what its pull request tested, and CI doesn't run again there.
Releasing
Merge as many pull requests as you like, then release main:
scripts/release.sh --dry-run v0.2.0 # the notes the release would have
scripts/release.sh v0.2.0 # CHANGELOG.md, commit, tag, push
It refuses unless you're on a clean main that matches origin/main.
git-cliff (cliff.toml) writes CHANGELOG.md
from the pull request titles. The tag runs the release workflow
(.gitea/workflows/release.yml): it tests, then
GoReleaser (.goreleaser.yaml) builds the
archives and publishes a Gitea release with them and the release's
changelog section. Then scripts/github-release.mjs copies that release,
notes and files, to the GitHub mirror, with the GH_RELEASE_TOKEN
secret (a fine-grained token that can write the mirror's contents);
without the secret it skips that. goreleaser release --snapshot --clean builds the same archives locally, into dist/, without
publishing.
A suffix (v0.2.0-rc.1) makes a pre-release, which leaves CHANGELOG.md
alone.