Skip to content

fix(entrypoint): derive git author identity from gh api user - #9

Merged
MathurAditya724 merged 1 commit into
mainfrom
fix/git-author-identity
May 1, 2026
Merged

fix(entrypoint): derive git author identity from gh api user#9
MathurAditya724 merged 1 commit into
mainfrom
fix/git-author-identity

Conversation

@MathurAditya724

Copy link
Copy Markdown
Member

Two unrelated changes bundled because they came up together:

  1. Git author identity from gh — agents pushing commits inside cloned repos (~/dev/<owner>/<repo>) were inheriting whatever git fell back to, leaking an unrelated identity (e.g. getsentry-bot from an upstream image bake-in) onto bot-authored commits. Entrypoint now resolves the GH_TOKEN's owner via gh api user at startup and sets git's global user.name + user.email to match, using GitHub's noreply pattern (<id>+<login>@users.noreply.github.com). Fail-soft: if gh api user errors, falls back to the existing default.

  2. Design doc for session reuse.opencode/plans/session-reuse-and-event-buffer.md lays out a per-PR session model with a FIFO event buffer to replace today's one-session-per-webhook dispatch. Just the plan; implementation in a follow-up PR.

Testing

  • sh -n docker-entrypoint.sh (syntax check passes).
  • jq confirmed already in the image (Dockerfile:115).
  • Manual local boot test pending — the env-var-only path can't be tested cleanly outside the container.

Agents committing inside cloned repos (~/dev/<owner>/<repo>) were
inheriting whatever git fell back to — which leaked an unrelated
identity (e.g. 'getsentry-bot' from an upstream image bake-in) onto
every commit the bot pushed.

Resolve the GH_TOKEN's owner via 'gh api user' at container start
and set git's global user.name + user.email accordingly. Email uses
GitHub's noreply pattern (<id>+<login>@users.noreply.github.com) so
attribution resolves to the bot's actual GitHub user without exposing
a private email. Written globally so every clone inherits it; also
overwrites the ~/dev repo-local config to clear any stale identity.

Fail-soft: if 'gh api user' errors, falls back to the existing
'Developer / developer@my-opencode.local' default for the worktree.

Also tracks .opencode/plans/session-reuse-and-event-buffer.md — design
doc for an upcoming change that reuses one OpenCode session per PR
across the full event lifecycle (review, fix, ci-fix, comment-respond)
with FIFO event buffering, instead of spawning a fresh session per
webhook delivery. Implementation deferred to a follow-up PR; this
commit just lands the plan for review.
@MathurAditya724
MathurAditya724 marked this pull request as ready for review May 1, 2026 05:51
@MathurAditya724
MathurAditya724 merged commit a335e8b into main May 1, 2026
1 check passed
@MathurAditya724
MathurAditya724 deleted the fix/git-author-identity branch May 1, 2026 05:51
MathurAditya724 added a commit that referenced this pull request May 1, 2026
Plans, scratch notes, and OpenCode session data are local-only.
The two plan docs that landed in #9 and earlier in this PR are
removed from tracking but remain on disk; past commits still
carry their content for anyone reading history.
MathurAditya724 added a commit that referenced this pull request May 1, 2026
* feat(plugin): extract github-webhooks as a publishable package

Moves the github-webhooks plugin from `plugins/github-webhooks{,.ts}` to
`packages/opencode-webhooks/` so it can be published to npm and consumed
by other OpenCode users via the standard `plugin: ["opencode-webhooks"]`
config pattern (matching how lore is consumed today).

Internal consumption (this image) is unchanged in behavior:
- `opencode-config-package.json` declares the package as a `file:` dep,
- Dockerfile copies `packages/` and `bun install` resolves it into
  `~/.config/opencode/node_modules/opencode-webhooks/`,
- `opencode-user-config.json` references the resolved path.

Decoupling: only the default DB path changed. Was hardcoded to
`~/dev/.opencode/github-webhooks.sqlite` (assumes the image's symlinked
volume); now defaults to `${XDG_DATA_HOME:-~/.local/share}/opencode-webhooks/deliveries.sqlite`.
The image's existing `webhooks.json` is updated with an explicit
`db_path` override to preserve the existing dedup history.

Other behavior is bit-identical:
- HMAC verification, identity gating, payload filters, prompt templating,
  bot identity resolution via `gh api user` — all unchanged.
- The plugin's log prefix changed `[github-webhooks]` → `[opencode-webhooks]`
  to match the package name.
- Health check response field changed from `{plugin: "github-webhooks"}`
  to `{plugin: "opencode-webhooks"}` (public API surface, callout in PR).

Out of scope and tracked as follow-ups in the plan doc:
- npm publishing workflow (will simplify the image's wiring once shipped),
- decoupling the `gh` CLI dependency,
- session reuse + event buffering.

See `.opencode/plans/extract-webhooks-plugin-package.md` for the full
design rationale, including a fact-check against OpenCode's plugin docs.

* chore: gitignore .opencode/ workspace state

Plans, scratch notes, and OpenCode session data are local-only.
The two plan docs that landed in #9 and earlier in this PR are
removed from tracking but remain on disk; past commits still
carry their content for anyone reading history.

* fix(plugin): bump peer dep floor + fail loudly on non-Bun runtimes

Two minor review-followup items on PR #10:

1. peerDependencies floor was `@opencode-ai/plugin: >=1.1.0` but version
   1.1.0 was never published to npm. The first existing version
   at-or-above the stated floor is 1.1.1. Range was still semver-valid
   so nothing broke, just an arbitrary floor — bump to >=1.1.1 so the
   stated floor is also resolvable.

2. Source-only TS distribution requires Bun at runtime (uses Bun.serve,
   Bun.spawn, Bun.file, bun:sqlite). README documents this and
   engines.bun is declared, but engines is advisory and a Node-on-Bun-
   fork consumer would have hit a cryptic ReferenceError on first
   dispatch. Add an explicit guard at the top of the plugin function
   that throws a useful message pointing at bun.sh.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant