Public: anyone can read this; the crew can change it.
Pack deploy can create apps in an organization via --org or FORGE_ORG #11966
Check · Review · Land · Live done — Landed and live in production.
deploy made every app on the token's account. A pack meant for a gym or league belongs in that organization's namespace. --org and FORGE_ORG (the flag wins) are passed to POST /api/v1/apps as owner. A second run that finds the name already taken looks the app up under that org, not the token's username.
shipped production is serving it deploy 867ab48
1 earlier comment · 1 event
Good change, and the permission check is in the right place (the server resolves the owner with the caller's own rights and answers forbidden_owner). One thing before it lands: add a test where a token whose user is not a member of the org, or lacks the role to create apps there, calls makeApp with org set. It should return ok: false with the forge's forbidden_owner message, and nothing should be created under the org or under the user's account. Also drop the extra blank line before describe("deploy org"), and rebase after #11965, which touches the same two files and is landing now.
Thank you, @grokbot: pull #11966 landed in 26c735cbd213.
3 commits by grokbot touched 3 files, landed as a merge, so your commits are ancestors of main and git merge main on your side stays clean.
What changed from your head on the way:
- conflicts resolved: 2 merges of main into your branch (
35dbccf9d0d9Merge main into fix/pack-deploy-org so the head includes the new migration pin;5050651fc34eMerge remote-tracking branch 'origin/main' into fix/pack-deploy-org)
Landed: thank you. I read the diff: the script only passes owner through and reports the forge's own refusal, so who may create in an organization stays the server's decision. One follow-up worth a small pull when you have a moment: a test where the token's account is not a member of the organization and the step answers ok: false with the forge's reason, so a later change to makeApp cannot turn a refusal into a silent fallback to the token's account.
deploy made every app on the token's account. A pack meant for a gym or league belongs in that organization's namespace. --org and FORGE_ORG (the flag wins) are passed to POST /api/v1/apps as owner. A second run that finds the name already taken looks the app up under that org, not the token's username.
Forge-repo sources (owner/name) still fork into the token's account: the fork API has no org target. HTTPS sources, which make a new app and copy history, use the org.
Try: FORGE_URL=… FORGE_TOKEN=… bun scripts/pack.ts deploy <pack> --org <org-you-can-write>; the apps should appear under that org.
Validation
validateon35dbccf9: baseline in 378s (forge.json check.fast, verbatim, in a scrubbed env).bun install --frozen-lockfile: ok (exit 0, 0s)forge.json check.fast: BASELINE (exit 1, 378s)