Skip to content

feat(push): push change-requests from the container (CR-1021) - #15

Draft
StoneyJackson wants to merge 14 commits into
mainfrom
cr-1021-push-from-container
Draft

StoneyJackson wants to merge 14 commits into
mainfrom
cr-1021-push-from-container

Conversation

@StoneyJackson

Copy link
Copy Markdown
Member

CR-1021, Rollout step 3 of the devcontainer permissions spec.

  • bin/push.bash: under flock -o -w 120 /workspaces/dev, it fetches, rebases onto origin/main, runs check.py --pre-push --root, and pushes. It refuses with a one-line reason on uncommitted changes, a branch other than main, a rebase in progress, a conflict, a failed check, a failed push, or a lock timeout. 18 tests in tests/test_push.py.
  • ORG-AGENTS.md: never merge a PR; never run gh auth login, refresh, or token; push change-requests only through bin/push.bash.
  • dev-docs/tracker.md: push from the container with bin/push.bash.
  • CONTRIBUTING.md: a new section on working in a devcontainer.
  • .gitattributes: * text=auto eol=lf.

Merge order: the spec PR first, then this one in cutover step 6, after the split's PR (cutover step 4).

🤖 Generated with Claude Code"

StoneyJackson and others added 9 commits October 13, 2026 14:56
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Also say in the docs that the tracker data lives in change-requests.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Lock the volume's mount point rather than the script's own repo, so a
worktree's copy still serializes with other containers; tests lock a
temp dir through OURPLCC_LOCK_DIR. Reject an unfinished clone, a rebase
already in progress, and a rebase that fails without a conflict with a
push.bash: message instead of raw git errors, never leaving a rebase
half done. Point a failed push at git's message and the token. Warn
before CONTRIBUTING's reset --hard.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Copilot AI balanced review requested due to automatic review settings October 13, 2026 17:27

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

@StoneyJackson
StoneyJackson marked this pull request as draft October 13, 2026 17:33
StoneyJackson and others added 5 commits October 27, 2026 12:09
Brings in main's edits to the devcontainer permissions spec, which the
open-check results amend next.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Settled on plcc-ng's branch: the forwarded SSH agent can only be hidden,
so the boundary is keeping no GitHub key in the host agent; the Codespace
token can create draft releases; its token expires about 12 hours after
start and Codespaces' own helper is no fresher, so the fallback helper is
dropped; volumes survive a Codespace restart; the lock crosses containers.
Verification narrows to a smoke test for repos after plcc-ng.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A workflow's permissions block can raise the read-only GITHUB_TOKEN
default, so a workflow pushed from a Codespace runs with write access to
its repo. Accepted; CONTRIBUTING advises running agents regularly in a
local container and only watched one-offs in a Codespace.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Naming them tells a phisher whose token is worth taking; the spec needs
only the exception, not the person.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The spec assumed OAuth app access was unrestricted so that hosts could
push through Git Credential Manager. It was already restricted, which
cut GCM off and also stops gh's browser-login token reaching ourPLCC.
Keep the restriction, approve GCM alone, and add the host's switch to
HTTPS through GCM to the migration.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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.

2 participants