feat: add reusable publish-preview workflow by cryptodev-2s · Pull Request #223 · MetaMask/github-tools

cryptodev-2s · 2026-02-26T15:10:14Z

Add a reusable workflow_call workflow so consumer repos can replace their copy-pasted publish-preview.yml with a thin wrapper.

New files

.github/workflows/publish-preview.yml — Reusable workflow with 4 jobs: fork check, comment reaction, build (no token), publish (with token). Supports both monorepos and polyrepos via is-monorepo input.
.github/scripts/generate-preview-build-message.sh — Generates the PR comment (collapsible package list for monorepos, single install command for polyrepos).
.github/actions/prepare-preview-builds/ — Composite action for monorepo manifest preparation (from prior commit).

Consumer example

name: Publish a preview build
on:
  issue_comment:
    types: created
jobs:
  publish-preview:
    if: ${{ github.event.issue.pull_request && startsWith(github.event.comment.body, '@metamaskbot publish-preview') }}
    uses: MetaMask/github-tools/.github/workflows/publish-preview.yml@v2
    with:
      is-monorepo: false  # omit for monorepos (default: true)
      environment: default-branch  # optional
    secrets:
      PUBLISH_PREVIEW_NPM_TOKEN: ${{ secrets.PUBLISH_PREVIEW_NPM_TOKEN }}

Extract the preview build preparation logic into a reusable composite GitHub Action so other repos can use the same logic. The jq filter is inlined and the source scope is parameterized.

.github/actions/prepare-preview-builds/action.yml

mcmire · 2026-02-26T16:09:42Z

@cryptodev-2s What are your thoughts on supporting the entire preview build workflow rather than just the "generate preview builds" step? Recently, we've added support for preview builds to other polyrepos, but currently we have to copy around the workflows. It would be nice to consolidate all of the steps into this repo. And we could make the action support both monorepos and polyrepos. What do you think?

cryptodev-2s · 2026-02-26T16:11:02Z

@cryptodev-2s What are your thoughts on supporting the entire preview build workflow rather than just the "generate preview builds" step? Recently, we've added support for preview builds to other polyrepos, but currently we have to copy around the workflows. It would be nice to consolidate all of the steps into this repo. And we could make the action support both monorepos and polyrepos. What do you think?

Yes make sense, let me do this.

Add a `workflow_call` workflow that handles the full preview build flow (fork check, comment reaction, build, publish) for both monorepos and polyrepos. Consumer repos only need a ~13-line thin wrapper with the `issue_comment` trigger. Also add a centralized `generate-preview-build-message.sh` script that auto-detects mono vs polyrepo and produces the appropriate PR comment.

cursor · 2026-02-27T00:07:35Z

.github/workflows/publish-preview.yml

+
+      - name: Prepare preview builds (monorepo)
+        if: ${{ inputs.is-monorepo }}
+        uses: MetaMask/github-tools/.github/actions/prepare-preview-builds@prepare-preview-builds-action


Hardcoded branch ref will break after PR merge

High Severity

The uses: reference at @prepare-preview-builds-action points to what appears to be this PR's development branch. Once the PR is merged and the branch is deleted, the monorepo build step will fail for every consumer of this reusable workflow. The publish job correctly resolves the ref dynamically from github.workflow_ref, but the build job hardcodes this ephemeral branch name instead.

Additional Locations (1)

.github/workflows/publish-preview.yml#L168-L183

cursor

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

.github/workflows/publish-preview.yml

cursor · 2026-03-04T19:36:10Z

.github/workflows/publish-preview.yml

+            !./packages/*/node_modules/
+            !./packages/*/src/
+            !./packages/*/tests/
+            !./packages/**/*.test.*


Monorepo artifact paths hardcode packages/ directory structure

Medium Severity

The monorepo upload glob ./packages/*/ and the sanitization find packages both hardcode the packages/ directory. However, prepare-preview-builds.sh dynamically discovers workspaces via yarn workspaces list, which works for any directory layout. Monorepos with workspaces outside packages/ (e.g., libs/, modules/) would have their manifests prepared but the built output wouldn't be uploaded or security-validated before publishing.

Additional Locations (1)

.github/workflows/publish-preview.yml#L196-L197

All MetaMask monorepos use packages/, this matches the existing core workflow convention. If a repo ever uses a different layout, we can add a workspace-glob input then.

We could generate this glob automatically by looping through the workspaces field in package.json. But yes I agree that probably don't need to worry about this for v1.

mcmire · 2026-03-05T21:06:01Z

.github/workflows/publish-preview.yml

What do you think about turning this into an action and then merging the prepare-preview-builds action into it?

(I have made suggestions below as if the workflow is not being converted, FYI)

mcmire · 2026-03-05T21:09:35Z

.github/workflows/publish-preview.yml

+      - name: Sanitize and validate artifact manifests
+        run: |
+          bad=0
+          if [[ "${{ inputs.is-monorepo }}" == "true" ]]; then


Instead of injecting this should we set it in an environment variable and then read the variable?

mcmire · 2026-03-05T21:14:55Z

.github/scripts/generate-preview-build-message.sh

+  # Build a JSON object of { name: version } for all non-root workspace packages.
+  package_json="$(
+    yarn workspaces list --no-private --json \
+      | jq --slurp '[.[] | select(.location != ".")] | .[].location' --raw-output \


Do we need to omit .? I thought --no-private should take care of that:

Suggested change

| jq --slurp '[.[] | select(.location != ".")] | .[].location' --raw-output \

| jq --slurp --raw-output '.[].location' \

mcmire · 2026-03-05T21:23:30Z

.github/scripts/generate-preview-build-message.sh

+  cat > preview-build-message.txt <<MSGEOF
+Preview builds have been published.${docs_link}
+
+\`\`\`
+yarn add ${name}@${version}
+\`\`\`
+MSGEOF


Wondering if we should say:

Suggested change

cat > preview-build-message.txt <<MSGEOF

Preview builds have been published.${docs_link}

\`\`\`

yarn add ${name}@${version}

\`\`\`

MSGEOF

cat <<-MSGEOF > preview-build-message.txt

The following preview build has been published:

\`\`\`

${name}@${version}

\`\`\`

MSGEOF

if [[ -n $docs_link ]]; then

cat <<-MSGEOF >> preview-build-message.txt

${docs_link}

MSGEOF

fi

mcmire · 2026-03-05T21:26:00Z

.github/scripts/generate-preview-build-message.sh

+  cat > preview-build-message.txt <<MSGEOF
+Preview builds have been published.${docs_link}
+
+<details>
+
+<summary>Expand for full list of packages and versions.</summary>
+
+\`\`\`
+${package_json}
+\`\`\`
+
+</details>
+MSGEOF


Wondering if we should say:

Suggested change

cat > preview-build-message.txt <<MSGEOF

Preview builds have been published.${docs_link}

<details>

<summary>Expand for full list of packages and versions.</summary>

\`\`\`

${package_json}

\`\`\`

</details>

MSGEOF

cat <<-MSGEOF > preview-build-message.txt

Preview builds have been published.

MSGEOF

if [[ -n $docs_link ]]; then

echo -n " ${docs_link}" >> preview-build-message.txt

fi

cat <<-MSGEOF >> preview-build-message.txt

<details>

<summary>Expand for full list of packages and versions.</summary>

\`\`\`

${package_json}

\`\`\`

</details>

MSGEOF

mcmire · 2026-03-05T21:28:12Z

.github/scripts/prepare-preview-builds.sh

+while IFS=$'\t' read -r location name; do
+  echo "- $name"
+  prepare-preview-manifest "$location/package.json"
+done < <(yarn workspaces list --no-private --json | jq --slurp --raw-output 'map(select(.location != ".")) | map([.location, .name]) | map(@tsv) | .[]')


I know that the script in core does this, but now that I look at this, do we need to exclude . here either? --no-private should take care of this as well.

Suggested change

done < <(yarn workspaces list --no-private --json | jq --slurp --raw-output 'map(select(.location != ".")) | map([.location, .name]) | map(@tsv) | .[]')

done < <(yarn workspaces list --no-private --json | jq --slurp --raw-output 'map([.location, .name]) | map(@tsv) | .[]')

mcmire · 2026-03-05T21:36:58Z

.github/scripts/generate-preview-build-message.sh

+  # Build a JSON object of { name: version } for all non-root workspace packages.
+  package_json="$(
+    yarn workspaces list --no-private --json \
+      | jq --slurp '[.[] | select(.location != ".")] | .[].location' --raw-output \
+      | while read -r location; do
+          jq '{ (.name): .version }' "$location/package.json"
+        done \
+      | jq --slurp 'add'
+  )"


A few things:

Instead of building an object here what do you think about listing out the names and versions? The current way that we output the list of versions makes it difficult to update a project's package.json manually.

Do we need to omit .? I thought --no-private should take care of that.

We can use xargs instead of a loop. There is a script in core that does something very similar: https://github.com/MetaMask/core/blob/416032dbbed5c2bf1340572964a09c91d6e06dc7/scripts/list-workspace-versions.sh

Suggested change

# Build a JSON object of { name: version } for all non-root workspace packages.

package_json="$(

yarn workspaces list --no-private --json \

| jq --slurp '[.[] | select(.location != ".")] | .[].location' --raw-output \

| while read -r location; do

jq '{ (.name): .version }' "$location/package.json"

done \

| jq --slurp 'add'

)"

# Build a list of "<name>@<version>" for all non-root workspace packages.

packages="$(

yarn workspaces list --no-private --json | \

jq --raw-output '.location' | \

xargs -I{} cat '{}/package.json' | \

jq --raw-output '"\(.name)@\(.version)"'

)"

mcmire · 2026-03-05T21:38:15Z

.github/workflows/publish-preview.yml

+      - name: Generate preview build message
+        run: |
+          args=()
+          if [[ "${{ inputs.is-monorepo }}" == "true" ]]; then


Should we use environment variables instead of reading inputs directly?

mcmire · 2026-03-05T21:39:43Z

.github/workflows/publish-preview.yml

+            !./packages/*/node_modules/
+            !./packages/*/src/
+            !./packages/*/tests/
+            !./packages/**/*.test.*


We could generate this glob automatically by looping through the workspaces field in package.json. But yes I agree that probably don't need to worry about this for v1.

mcmire · 2026-03-05T21:43:34Z

.github/workflows/publish-preview.yml

+        with:
+          name: preview-build-artifacts
+
+      - name: Resolve GitHub tools ref


Is this step necessary? I see that for instance check-changelog reads github.action_ref.

feat: add prepare-preview-builds composite action

06b127c

Extract the preview build preparation logic into a reusable composite GitHub Action so other repos can use the same logic. The jq filter is inlined and the source scope is parameterized.

cryptodev-2s mentioned this pull request Feb 26, 2026

feat: use reusable publish-preview workflow from github-tools MetaMask/core#8050

Draft

cryptodev-2s self-assigned this Feb 26, 2026

cryptodev-2s added the team-core-platform label Feb 26, 2026

cryptodev-2s marked this pull request as ready for review February 26, 2026 15:37

cursor bot reviewed Feb 26, 2026

View reviewed changes

.github/actions/prepare-preview-builds/action.yml Outdated Show resolved Hide resolved

cryptodev-2s changed the title ~~feat: add prepare-preview-builds composite action~~ feat: add reusable publish-preview workflow Feb 26, 2026

cryptodev-2s added 3 commits February 27, 2026 00:27

fix: use absolute script path in prepare-preview-builds action

5a9d9bc

test: point prepare-preview-builds action at branch ref

0f2aa18

fix: resolve github-tools ref from github.workflow_ref

08df742

cursor bot reviewed Feb 27, 2026

View reviewed changes

cryptodev-2s requested review from Mrtenz and mcmire March 4, 2026 15:04

cryptodev-2s added 2 commits March 4, 2026 15:31

fix: run yarn install after polyrepo package rename

c65f89b

fix: strip lifecycle scripts from artifacts instead of failing

fa010ba

cursor bot reviewed Mar 4, 2026

View reviewed changes

cryptodev-2s added 2 commits March 5, 2026 15:30

fix: also strip prepare lifecycle script from artifacts

fad8410

refactor: pass monorepo/polyrepo flag explicitly to message script

5fa209e

cryptodev-2s requested review from FrederikBolding, Gudahtt and GuillaumeRx March 5, 2026 15:54

mcmire reviewed Mar 5, 2026

View reviewed changes

	\| jq --slurp '[.[] \| select(.location != ".")] \| .[].location' --raw-output \
	\| jq --slurp --raw-output '.[].location' \

	done < <(yarn workspaces list --no-private --json \| jq --slurp --raw-output 'map(select(.location != ".")) \| map([.location, .name]) \| map(@tsv) \| .[]')
	done < <(yarn workspaces list --no-private --json \| jq --slurp --raw-output 'map([.location, .name]) \| map(@tsv) \| .[]')

Uh oh!

Conversation

cryptodev-2s commented Feb 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

New files

Consumer example

Uh oh!

Uh oh!

mcmire commented Feb 26, 2026

Uh oh!

cryptodev-2s commented Feb 26, 2026

Uh oh!

cursor bot Feb 27, 2026

Choose a reason for hiding this comment

Hardcoded branch ref will break after PR merge

Uh oh!

cursor bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

cursor bot Mar 4, 2026

Choose a reason for hiding this comment

Monorepo artifact paths hardcode packages/ directory structure

Uh oh!

cryptodev-2s Mar 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mcmire Mar 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mcmire Mar 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mcmire Mar 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

cryptodev-2s commented Feb 26, 2026 •

edited

Loading

Monorepo artifact paths hardcode `packages/` directory structure

cryptodev-2s Mar 5, 2026 •

edited

Loading

mcmire Mar 5, 2026 •

edited

Loading

mcmire Mar 5, 2026 •

edited

Loading

mcmire Mar 5, 2026 •

edited

Loading