From 65deb66989fdbdde753f656211c3ed10992f9211 Mon Sep 17 00:00:00 2001 From: Eric Wang Date: Mon, 23 Jun 2025 06:31:11 -0700 Subject: [PATCH] chore: prepare v0.2.4 release --- .claude/settings.local.json | 1 + .cursor/rules/notes.mdc | 39 ++++++++++ CHANGELOG.md | 46 ++++++++++++ workflows/GIT-COMMIT.md | 144 ++++++++++++++++++++++++++++++++++++ workflows/GITHUB-ISSUE.md | 29 ++++++++ workflows/GITHUB-PR.md | 5 ++ 6 files changed, 264 insertions(+) create mode 100644 .claude/settings.local.json create mode 100644 .cursor/rules/notes.mdc create mode 100644 workflows/GIT-COMMIT.md create mode 100644 workflows/GITHUB-ISSUE.md create mode 100644 workflows/GITHUB-PR.md diff --git a/.claude/settings.local.json b/.claude/settings.local.json new file mode 100644 index 0000000..0967ef4 --- /dev/null +++ b/.claude/settings.local.json @@ -0,0 +1 @@ +{} diff --git a/.cursor/rules/notes.mdc b/.cursor/rules/notes.mdc new file mode 100644 index 0000000..9743ab3 --- /dev/null +++ b/.cursor/rules/notes.mdc @@ -0,0 +1,39 @@ +--- +description: +globs: +alwaysApply: true +--- +[best-practice] Use npm config set prefix /usr/local before installing Claude CLI for non-root access +[optimization] Use gosu for privilege dropping - better than su for containers +[design] Create symlinks for auth files instead of copying to preserve host-container sync +[gotcha] HOME environment variable needs explicit handling with gosu: export HOME=/home/claude + +[design] Mount auth to /root/ but use symlinks from /home/claude/ for non-root access +[best-practice] Use chmod 755 on /root and auth dirs + symlinks for non-root user +[gotcha] Non-root user expects auth in $HOME/.claude but mounted to /root/.claude + +[design] Remove emoji-heavy messages for clean Linux-style output +[best-practice] Use concise error/warning prefixes like error: and warning: +[optimization] Eliminate verbose startup messages for faster perceived launch + +[best-practice] Add dangerous directory detection to prevent running in home/system dirs +[design] Interactive prompt requires explicit yes to continue in dangerous directories +[gotcha] Running --yolo in $HOME gives Claude access to ALL personal files + +[best-practice] Follow Keep a Changelog format for CHANGELOG.md +[design] Default to non-root mode with --dangerously-skip-permissions always added in YOLO mode +[gotcha] Docker socket should not be mounted by default - use CLAUDE_YOLO_DOCKER_SOCKET=true + +[design] Keep TODO lists minimal and actionable - overwhelming lists lead to paralysis + +[design] Flexible volume mounting > hardcoded config directories +[best-practice] Use familiar Docker -v syntax for volume arguments +[optimization] Pass volumes via env var to avoid complex arg parsing between scripts +[gotcha] Space-separated env vars need careful parsing to handle paths with spaces +[gotcha] -v flag conflicts with Vertex AI auth - use --mount for volumes instead + +[optimization] Symlink all /root/* to /home/claude/* - simpler than individual mappings +[design] Auto-discovery > hardcoded tool list - loop through /root/* for symlinks +[best-practice] Skip . and .. when iterating directories to avoid infinite loops +[gotcha] Read-only protection via Docker mount :ro flag, not file permissions +[best-practice] Keep full permissions inside container - Claude needs them to function diff --git a/CHANGELOG.md b/CHANGELOG.md index 43711e0..5281270 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -7,6 +7,8 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0 ## [Unreleased] +## [0.2.4] - 2025-06-23 + ### Added - Unified logging system for improved UX - Clean output by default showing only authentication method @@ -27,6 +29,50 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0 ### Performance - Docker build caching in GitHub Actions (dual GHA + registry cache strategy) +## [0.2.3] - 2025-06-23 + +### Added +- Dynamic fallback UID/GID selection for root users + +### Fixed +- Handle UID 0 (root user) case in docker-entrypoint.sh +- Add explicit github_token to claude-code-review action +- Handle UID=0 and GID=0 independently for security + +### Changed +- Simplify root user handling with hardcoded 1000 fallback +- Remove redundant comments in UID/GID handling +- Run Claude review once per PR and on manual trigger + +### Performance +- Docker build caching improvements in GitHub Actions + +### Documentation +- Update logs and changelog for issue #19 caching fix +- Clarify root cause and solution for UID 0 handling +- Add OIDC token fix to dev log + +## [0.2.2] - 2025-06-23 + +### Added +- Docker image update to ghcr.io with fallback to Docker Hub +- Note when falling back to Docker Hub image in installer + +### Fixed +- Set shellcheck to error severity to prevent CI blocking + +### Documentation +- Improve usage examples across all documentation + +## [0.2.1] - 2025-06-23 + +### Fixed +- Move shellcheck to CI workflow, remove from release + +## [0.2.0] - 2025-06-23 + +### Added +- --verbose flag to show environment info and pass to Docker ## [0.1.0] - 2025-06-21 diff --git a/workflows/GIT-COMMIT.md b/workflows/GIT-COMMIT.md new file mode 100644 index 0000000..461a2c2 --- /dev/null +++ b/workflows/GIT-COMMIT.md @@ -0,0 +1,144 @@ +Perform as you are an expert software engineer and meticulous code reviewer. +Your task is to review the code, and generate a single Git commit message. + +# GIT Commit Workflow +- First perform a through code review on the current git state, including staged changes, git branch name, find if + there are any obvious debug statements, bad naming, typos, and potential BUGs; +- Then If current branch does not reflect the changes, checkout to new branch with a very short descriptive name; +- Finally, generate a single commit message that strictly follows the following instruction; + +## Good work! We're in pre-release stage now! + +BUT before release let us ensure everything is ready. +- Check if we've added related dev logs in @DEV-LOGS.md; +- Check if we've added a version tag; +- Check if we've updated the @CHANGELOG.md accordingly to current changes or commit; +- Check if we should update the @README.md with new features, usage, etc; + +--- + + +### PRIMARY GOAL + +Produce one short, complete commit message for the staged changes. + +### OUTPUT FORMAT +- We're fullstack but majoring in backend system so we'd always prefer linux-style and Linus Torvalds's tone. +- We write or explain to the damn point. Be clear, be super concise - no fluff, no hand-holding, no repeating. +- Minimal markdown markers, no unnecessary formatting. +- We'd prefer ascii arts, so be minimal unicode emojis. +- Return **only** the commit message text—no code fences, no commentary, no extra markup or explanations. +- The summary (first) line **must** be imperative, present tense, ≤72 characters, and **must not** end with a period. +- Wrap all body lines at a maximum of 72 characters. +- If a body is included, format it as a clean, concise bullet list, each line starting with - . +- If the staged diff includes obvious debug statements (`print`, `console.log`, `dbg!`, `puts`, etc.), append a new line at the end of the body starting with + `WARNING: Contains debug statements: `. + +--- + +### SPEC FOR YOUR REFERENCE + +Conventional Commits 1.0.0 +========================== + +Structure +========= + +The commit message should be structured as follows: +``` +[optional scope]: + +[optional body] (super clean, concise bullet list ) + +[optional footer(s)] (like Close #11, BREAKING CHANGE, etc.) +``` + +Type Definitions +============== + +Each commit type has a specific meaning and purpose: + +- **fix**: A commit that patches a bug in your codebase +- **feat**: A commit that introduces a new feature to the codebase +- **build**: Changes that affect the build system or external dependencies +- **chore**: Changes to the build process or auxiliary tools and libraries +- **ci**: Changes to CI configuration files and scripts +- **docs**: Documentation only changes +- **perf**: A code change that improves performance +- **refactor**: A code change that neither fixes a bug nor adds a feature +- **style**: Changes that do not affect the meaning of the code +- **test**: Adding missing tests or correcting existing tests + +Note: Types other than \"fix:\" and \"feat:\" are allowed and have no implicit effect in semantic versioning (unless they include a BREAKING CHANGE). + +Detailed Rules +============= + +The key words \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL NOT\", \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\", \"MAY\", and \"OPTIONAL\" in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt). + +1. Commits MUST be prefixed with a type, which consists of a noun, `feat`, `fix`, etc., followed by the OPTIONAL scope, OPTIONAL `!`, and REQUIRED terminal colon and space. +2. The type `feat` MUST be used when a commit adds a new feature to your application or library. +3. The type `fix` MUST be used when a commit represents a bug fix for your application. +4. A scope MAY be provided after a type. A scope MUST consist of a noun describing a section of the codebase surrounded by parenthesis, e.g., `fix(parser):` +5. A description MUST immediately follow the colon and space after the type/scope prefix. The description is a short summary of the code changes, e.g., _fix: array parsing issue when multiple spaces were contained in string_. +6. A longer commit body MAY be provided after the short description, providing additional contextual information about the code changes. The body MUST begin one blank line after the description. +7. A commit body is free-form and MAY consist of any number of newline separated paragraphs. +8. One or more footers MAY be provided one blank line after the body. Each footer MUST consist of a word token, followed by either a `:` or `#` separator, followed by a string value (this is inspired by the [git trailer convention](https://git-scm.com/docs/git-interpret-trailers)). +9. A footer's token MUST use `-` in place of whitespace characters, e.g., `Acked-by` (this helps differentiate the footer section from a multi-paragraph body). An exception is made for `BREAKING CHANGE`, which MAY also be used as a token. +10. A footer's value MAY contain spaces and newlines, and parsing MUST terminate when the next valid footer token/separator pair is observed. +11. Breaking changes MUST be indicated in the type/scope prefix of a commit, or as an entry in the footer. +12. If included as a footer, a breaking change MUST consist of the uppercase text BREAKING CHANGE, followed by a colon, space, and description, e.g., _BREAKING CHANGE: environment variables now take precedence over config files_. +13. If included in the type/scope prefix, breaking changes MUST be indicated by a `!` immediately before the `:`. If `!` is used, `BREAKING CHANGE:` MAY be omitted from the footer section, and the commit description SHALL be used to describe the breaking change. +14. Types other than `feat` and `fix` MAY be used in your commit messages, e.g., _docs: update ref docs._ +15. The units of information that make up Conventional Commits MUST NOT be treated as case sensitive by implementors, with the exception of BREAKING CHANGE which MUST be uppercase. +16. BREAKING-CHANGE MUST be synonymous with BREAKING CHANGE, when used as a token in a footer. + +### Examples + +#### Commit message with description and breaking change footer +``` +feat: allow provided config object to extend other configs + +BREAKING CHANGE: `extends` key in config file is now used for extending other config files +``` + +#### Commit message with `!` to draw attention to breaking change +``` +feat!: send an email to the customer when a product is shipped +``` + +#### Commit message with scope and `!` to draw attention to breaking change +``` +feat(api)!: send an email to the customer when a product is shipped +``` + +#### Commit message with both `!` and BREAKING CHANGE footer +``` +chore!: drop support for Node 6 + +BREAKING CHANGE: use JavaScript features not available in Node 6. +``` + +#### Commit message with no body +``` +docs: correct spelling of CHANGELOG +``` + +#### Commit message with scope +``` +feat(lang): add Polish language +``` + +#### Commit message with multi-paragraph body and multiple footers +``` +fix: prevent racing of requests + +Introduce a request id and a reference to latest request. Dismiss +incoming responses other than from latest request. + +Remove timeouts which were used to mitigate the racing issue but are +obsolete now. + +Reviewed-by: Z +Refs: #123 +``` diff --git a/workflows/GITHUB-ISSUE.md b/workflows/GITHUB-ISSUE.md new file mode 100644 index 0000000..ce2532e --- /dev/null +++ b/workflows/GITHUB-ISSUE.md @@ -0,0 +1,29 @@ +- Use `gh issue create` to create issues. +- Create issues before implementing new features or fixing bugs; +- Mention the issue number in commits and PRs; +- Follow the issue template for consistency, be super brief and to the point; +- We're fullstack but majoring in backend system so we'd always prefer linux-style and Linus Torvalds's tone. +- We write or explain to the damn point. Be clear, be super concise - no fluff, no hand-holding, no repeating. +- Minimal markdown markers, no unnecessary formatting. +- Minimal unicode emojis. + +- ISSUE_TEMPLATE.md +``` markdown +## Description + + +## Type +- [ ] Bug fix +- [ ] New feature +- [ ] Enhancement +- [ ] Documentation + +## Details + + +## Related Files + + +## Test Plan + +``` diff --git a/workflows/GITHUB-PR.md b/workflows/GITHUB-PR.md new file mode 100644 index 0000000..11b4e2b --- /dev/null +++ b/workflows/GITHUB-PR.md @@ -0,0 +1,5 @@ +Use `gh` to create PR, mention to close related issues. +- We're fullstack but majoring in backend system so we'd always prefer linux-style and Linus Torvalds's tone. +- We write or explain to the damn point. Be clear, be super concise - no fluff, no hand-holding, no repeating. +- Minimal markdown markers, no unnecessary formatting. +- We'd prefer ascii arts, so be minimal unicode emojis.