You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Adds repository-level automated plugin releases. `emdash-plugin release setup` writes one shared `.github/workflows/emdash-release.yml` at the Git repository root, including when setup runs from a nested package. The workflow resolves `<slug>@<version>` tags to a unique plugin manifest, rejects version mismatches before attestation, and requests its first repository connection through GitHub OpenID Connect without an Actions secret.
7
+
8
+
Prepare later packages with `emdash-plugin profile setup --dir <package-directory>`. Their first release reuses approved repository workflow scopes when the signed package profile names the same repository. Tag and manual-run scopes accumulate after publisher confirmation instead of replacing each other. Existing package approvals remain package-scoped until the publisher explicitly confirms a repository connection; existing generated workflows and the legacy optional connection-invitation input remain supported.
Updates `emdash-plugin init` to produce a validated, package-manager-aware plugin project. Interactive setup shows the resolved publisher, author, security contact, repository, target, and package manager before writing. Non-interactive setup requires explicit ownership flags unless `--use-detected` opts into the active publisher session and local Git metadata.
6
+
7
+
Generated projects pin the plugin CLI version, use bounded EmDash dependencies, include validation and publishing scripts, and add `AGENTS.md` with a local `creating-plugins` skill. `.agents/skills` and `.claude/skills` link to the same canonical skill directory, while `.claude/CLAUDE.md` links to `AGENTS.md`. pnpm projects include the reviewed `esbuild` install policy and use an explicit `SandboxedPlugin` annotation so declaration output remains portable. The scaffolder validates the complete manifest and parent paths before writing and stages new projects atomically.
Copy file name to clipboardExpand all lines: apps/release-action/README.md
+17-18Lines changed: 17 additions & 18 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -15,13 +15,13 @@ emdash-plugin release setup
15
15
16
16
Before writing `.github/workflows/emdash-release.yml`, the command creates a missing package profile or adds delegated-release settings to an existing valid profile. Profile setup binds the package to the canonical GitHub repository, uses the signed-in [Atmosphere account](https://docs.emdashcms.com/plugins/creating-plugins/publishing/#your-atmosphere-account) as the initial approver, and asks whether approval is required for permission increases or every release. Run `emdash-plugin profile setup` to perform this step without changing the workflow file.
17
17
18
-
The generated workflow uses pinned third-party Actions, builds one bundle, creates GitHub provenance for the exact bundle, and calls this Action. It does not push the workflow. The generated workflow currently supports public repositories because the verifier trusts GitHub's public Sigstore root.
18
+
The generated root workflow uses pinned third-party Actions, resolves `<slug>@<version>` tags to one plugin package, builds one bundle, creates GitHub provenance for the exact bundle, and calls this Action. Every plugin package in the repository reuses the workflow. It does not push the workflow. The generated workflow currently supports public repositories because the verifier trusts GitHub's public Sigstore root.
19
19
20
-
Before the first run, create an invitation for the plugin in the publisher dashboard and add its one-time value to the repository as the `EMDASH_CONNECTION_INVITATION` Actions secret. The generated workflow passes that secret as `connection-invitation`.
20
+
Start the workflow by pushing a package tag such as `gallery@1.2.3`. The service checks that the signed package profile names the GitHub repository before creating a connection request. The Action writes an approval link to the job summary and waits. Open the link, sign in to the release service, and check the repository, workflow file, branch or tag, and environment reported by GitHub. After confirmation, the same Action run requests a fresh OIDC token and submits the release. Later packages reuse approved tag and branch scopes when their signed profiles name the same repository.
21
21
22
-
Start the workflow within 30 minutes. The Action consumes the invitation, writes an approval link to the job summary, and waits. Open the link, sign in to the release service, and check the repository, workflow file, branch or tag, and environment reported by GitHub. After confirmation, the same Action run requests a fresh OIDC token and submits the release. Later runs from the approved workflow continue without an invitation.
22
+
For tag-triggered releases, choose whether the workflow may publish all package version tags or only the current tag. The approval never grants authority by itself: the publisher's Atmosphere session must confirm the signed GitHub identity before the service creates a publishing policy.
23
23
24
-
For tag-triggered releases, choose whether the workflow may publish all version tags or only the current tag. The approval never grants authority by itself: the publisher's Atmosphere session must confirm the signed GitHub identity before the service creates a publishing policy.
24
+
A manual run from a branch requests approval the first time that branch is used. Confirming it adds the branch to the repository connection without removing approved tag or branch scopes. Package-scoped policies created by older workflows remain package-scoped until an unmatched package or ref is approved as a repository connection.
25
25
26
26
The Action accepts an existing `bundle-file`, or builds `plugin-directory` with the project's installed `emdash-plugin` command. Pass the raw `bundle-path` output from `actions/attest-build-provenance` as `provenance-file`. Before uploading either file, the Action confirms that the workflow is authorised and that the signed package profile links the same canonical repository. The service verifies the checksums and provenance before publishing.
27
27
@@ -39,26 +39,25 @@ The following step uses the bundle and provenance outputs created earlier in the
| `provenance-file` | Conditional | — | Raw Sigstore bundle under `RUNNER_TEMP`; required with a bundle or plugin directory. |
56
+
| `release-file` | No | — | Compatibility input for a URL-source release record inside `GITHUB_WORKSPACE`. |
57
+
| `idempotency-key` | No | Current run ID | Stable key used to replay the same submission. |
58
+
| `poll-interval-seconds` | No | `5` | Delay between intent status requests. |
59
+
| `timeout-minutes` | No | `30` | Maximum time to wait for workflow approval, publication, or release approval. |
60
+
| `wait-for-approval` | No | `false` | Continue polling when the intent reaches `awaiting_approval`. |
62
61
63
62
The default idempotency key is stable across attempts of one GitHub run. Set `idempotency-key` when separate runs or jobs must replay the same submission identity.
awaitruntime.writeSummary(`## Approve ${intent.packageSlug}${intent.version}\n\n[Open EmDash to review and approve the release](${intent.approvalUrl})`);
Copy file name to clipboardExpand all lines: apps/release-service/README.md
+6-4Lines changed: 6 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -21,10 +21,10 @@ The publisher and approver interfaces use the same Atmosphere account identity a
21
21
The service processes an automated release in this order:
22
22
23
23
1. The publisher authorises the exact create-only release and blob OAuth scope.
24
-
2. A GitHub Actions job presents a one-time invitation and a GitHub OIDC token.
25
-
3. The publisher checks the repository, workflow file, ref, and environment before confirming the connection.
26
-
4. The service verifies the signed package profile and its canonical repository before storing the workflow policy.
27
-
5. Every workflow run presents a fresh GitHub OIDC token. The service compares its repository, owner, workflow, ref, environment, commit, run, and runner claims with the stored policy.
24
+
2. A GitHub Actions job presents a GitHub OIDC token and the package selected by its `<slug>@<version>` tag.
25
+
3. The service verifies the signed package profile and its canonical repository before creating a pending connection request.
26
+
4. The publisher checks the repository, workflow file, ref, and environment before confirming the repository connection.
27
+
5. Every workflow run presents a fresh GitHub OIDC token. The service compares its repository, owner, workflow, ref, environment, commit, run, and runner claims with the stored policy. Packages whose signed profiles name the same repository reuse approved tag and branch scopes.
28
28
6. The Action uploads the bundle and raw Sigstore provenance to private R2 staging. Profile and workflow checks happen before these uploads.
29
29
7.`ReleaseIntentWorkflow` verifies the profile revision, release-key absence, artifact bytes, bundle manifest, declared access, GitHub provenance, and approval policy.
30
30
8. A release that expands declared access or uses `confirmation: always` waits for a profile-listed approver's passkey decision.
@@ -33,6 +33,8 @@ The service processes an automated release in this order:
33
33
34
34
An ambiguous PDS create enters reconciliation. The Workflow reads the deterministic release key and accepts only the exact expected record as published.
35
35
36
+
Confirming another tag or branch scope extends a repository connection without replacing existing scopes. Package policies created before repository connections remain package-scoped and cannot authorize another package.
37
+
36
38
## Authority boundaries
37
39
38
40
The service keeps each identity and credential separate.
0 commit comments