kacerr/egress-proxies-operator
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

Scaffold proxy-operator with kubebuilder v4.15.0 (go/v4)

Browse Source 
Bootstraps the empty repo into a kubebuilder go/v4 project: group
crawl.example.com, version v1alpha1, kind Proxy (namespaced). Keeps the
existing module path and preserves the repo's Go/testing/changelog
conventions from CLAUDE.md untouched.

Drops the scaffolded GitHub Actions workflows since the remote is Gitea,
not GitHub. Everything else is default kubebuilder output, unmodified,
so later diffs stay reviewable against a known baseline.

Full implementation plan: docs/plans/2026-08-07-1747-proxy-operator.md

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Jan Novak
2026-08-07 20:17:45 +02:00
commit 076bc66ebe
61 changed files with 4854 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
.claude/commands/release.md Normal file
View File

@@ -0,0 +1,10 @@
Commit all staged and unstaged changes into git, assign the next tag in sequence, then ask for confirmation before pushing.
Before committing, check the current branch (`git branch --show-current`). If it's
`main`, follow CLAUDE.md's Branching & Merge Requests exceptions (small fixes,
typos/formatting, or explicit user request) — otherwise stop and ask, since releases
are not one of the documented straight-to-main cases.
No tagging scheme (semver vs. calver, `v` prefix, etc.) is documented in CLAUDE.md
yet — infer the existing pattern from `git tag --list` if any tags exist, otherwise
ask the user which scheme to start with instead of guessing.

22
.claude/commands/ship.md Normal file
View File

@@ -0,0 +1,22 @@
---
description: Commit current changes and push to the remote
---
Commit the current working-tree changes and push them.
1. Run `git status` and `git diff` to see what will be committed.
2. Check the current branch (`git branch --show-current`). If it's `main` and the
change looks feature-sized (not one of CLAUDE.md's "commit straight to main"
exceptions: small fixes, typos/formatting, or the user explicitly said `main`),
stop and tell the user to branch first — don't push a feature to `main`.
3. Stage the changed files (`git add -A` is fine here).
4. Create a commit with a short message describing the changes (infer it from the
diff), including the `Co-Authored-By: Claude <noreply@anthropic.com>` trailer.
Pass the message via a HEREDOC.
5. Push with `git push`. If the current branch has no upstream, use `git push -u origin HEAD`.
6. If the branch isn't `main`, remind the user to open an MR with `tea pr create`
(see CLAUDE.md's Branching & Merge Requests section) rather than opening one
automatically.
7. Report the commit hash and push result.
If there are no changes, stop and say so — do not create an empty commit.