[sentry-junior]

Gives each changelog preview its own PR comment and status check, keyed by the workflow's working-directory, so one PR can carry a preview per package without them overwriting each other. Callers don't need to configure anything new.

Use case: one PR that touches two packages

Some repos release several packages from separate Craft configs. For example, getsentry/objectstore has a Python client and a Rust client, each with its own .craft.yml. The natural setup calls the preview workflow once per package:

jobs:
  changelog-preview-python:
    uses: getsentry/craft/.github/workflows/changelog-preview.yml@v3
    with:
      working-directory: clients/python
  changelog-preview-rust:
    uses: getsentry/craft/.github/workflows/changelog-preview.yml@v3
    with:
      working-directory: clients/rust

Now take a single PR that changes both clients, e.g. one that adds a new option to both.

Expected: two previews on the PR, one with the Python changelog entry and bump, one with the Rust one.

What happens today: both calls use the same hardcoded identity.

• Comment mode: both look up the comment containing the craft-changelog-preview HTML marker. The second run edits the first run's comment, so only one preview survives, and nothing says which package it's for.
• Status mode (comment: false): both post the commit status context Changelog Preview / Semver Impact. The last one wins, so the PR shows a single Minor or Patch without saying which package it applies to. The other package's preview is only visible if you open its Actions run.

The change

The preview ID is the working directory's repo-relative path, as reported by git rev-parse --show-prefix. Git normalizes it, so clients/python, ./clients/python/ and so on all give the same ID.

	Repo root (., the default)	working-directory: clients/python
Comment marker	craft-changelog-preview (unchanged)	craft-changelog-preview:clients/python
Status context	Changelog Preview / Semver Impact (unchanged)	Changelog Preview / Semver Impact (clients/python)
Heading	Semver Impact of This PR (unchanged)	Semver Impact of This PR (clients/python)

Two packages always run from different directories, since each has its own .craft.yml, so the directory is a natural key and there's no new input to learn.

• Root callers: nothing changes. Their output is byte-for-byte what it is today.
• Sanitising: the ID ends up inside an HTML comment and a jq string, so any character outside [A-Za-z0-9._/-] is replaced with -. When that changes the path, the first 8 characters of a hash of the real path are appended, e.g. packages/foo bar becomes packages/foo-bar~1a2b3c4d. So it stays separate from a real packages/foo-bar.
• Uppercase letters: GitHub compares status contexts case-insensitively, so packages/Python and packages/python would still share a status. Paths with uppercase letters get the hash too (packages/Python~…), so the IDs differ even after case folding.
• Readable IDs: all-lowercase paths that need no sanitising, which is the common case, stay readable and unhashed. ~ is never kept, so a hashed ID can't match an unhashed one.
• Single marker: the marker is now defined once (COMMENT_MARKER) and used for both writing and looking up the comment.
• Docs: a short "Multiple Previews per PR" section in docs/src/content/docs/github-actions.md, and the working-directory input description mentions it.

What existing callers will notice

These only apply to callers that already set a non-root working-directory:

• Status context is renamed to include the directory. If a repo made Changelog Preview / Semver Impact a required status, it needs updating. The status is always success, so I'd expect that to be rare.
• On PRs that are already open when they upgrade, the next run creates a new comment with the new marker, and the old one stops updating. That's a one-off. I chose not to adopt the old comment: a repo with both a root preview and a sub-directory preview would then have the two fight over it.

Testing

src/__tests__/changelog-preview-workflow.test.ts runs the real "Generate Changelog Preview" step from the workflow file, in a temp git repo. It uses a stubbed craft and a fake gh that stores comments and statuses in JSON files. Lookups go through the step's own --jq filter. Like GitHub, the fake replaces any status whose context matches case-insensitively. It checks that:

• the repo root keeps the original marker and heading, and updates an existing comment in place;
• packages/python and packages/rust each create and then update only their own comment, next to the root's;
• status mode posts distinct contexts per directory and the plain one for the root, with matching job summary headings;
• packages/python and packages/Python keep two separate statuses. This test is skipped on case-insensitive file systems, since both directories can't exist there;
• packages/foo bar and packages/foo-bar get different, stable markers.

The case test fails without this change and passes with it; the other directory tests fail against master's workflow. actionlint, prettier, eslint and tsc are clean. I haven't run it on a real PR.

Details

via Junior system actor event.

--

View Junior Session [Sentry]

[github-actions]

PR Preview Action v1.8.1
🚀 View preview at https://craft.sentry.dev/pr-preview/pr-924/
Built to branch gh-pages at 2026-10-25 16:06 UTC. Preview will be ready when the GitHub Pages deployment is complete.

[BYK]

Ah, sounds great and thanks for the PR! I wonder if we can share a single PR with multiple change logs, collapsed by default? Looks possible with your markers which we can even move into the <details> elements or something or workspace headers?

[MathurAditya724]

This adds useful monorepo preview isolation that is separate from the AI-summary work merged in #929. Two follow-ups below: avoid directory-identity collisions and preserve the behavior in automated regression tests.

[MathurAditya724]

Both earlier comments are addressed: normalization plus a hash separates sanitized paths, and committed fixture tests execute the actual preview step. The seven committed tests pass locally, with typechecking, ESLint and formatting also passing. Additional isolated probes passed for equivalent directory spellings, unsafe/Unicode names and CalVer behavior. One remaining status-mode collision is documented inline: GitHub compares status contexts case-insensitively, unlike comment markers. No other actionable correctness or DRY issues found in the three-file diff.