Skip to content

[HOLD]chore: update changeset-snapshot-publish script to accept a parameter… #5366

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 11 commits into
base: main
Choose a base branch
from
+25 −3
Open

[HOLD]chore: update changeset-snapshot-publish script to accept a parameter… #5366

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
11 commits
Select commit Hold shift + click to select a range
0b7c148
chore: update changeset-snapshot-publish script to accept a parameter…
blunteshwar Apr 11, 2025
03992b9
chore: enhance beta release workflow to dynamically determine next be…
blunteshwar Apr 11, 2025
15d5359
chore: update beta release workflow to reference specific package ver…
blunteshwar Apr 11, 2025
ec84db1
Merge branch 'main' into pvashish/update-snapshot-script
blunteshwar Apr 11, 2025
b7e5e57
Merge branch 'main' into pvashish/update-snapshot-script
blunteshwar Apr 11, 2025
fbac9b2
chore: update beta release workflow to reference the bundle package v…
blunteshwar Apr 11, 2025
92511b4
chore: simplify beta release workflow by removing redundant current v…
blunteshwar Apr 11, 2025
6dba871
chore: add support for additional branch in beta release workflow
blunteshwar Apr 11, 2025
a8736cd
chore: add changeset pre exit step to beta release workflow
blunteshwar Apr 11, 2025
65a9534
chore: remove obsolete branch reference from beta release workflow
blunteshwar Apr 11, 2025
abcadcd
Merge branch 'main' into pvashish/update-snapshot-script
blunteshwar Apr 14, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 24 additions & 2 deletions .github/workflows/beta-release.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -21,11 +21,32 @@ jobs:
git config --global user.email "[email protected]"
git config --global user.name "github-actions-bot"

- name: Get current package version and latest beta number
id: version-info
run: |
# Fetch the latest beta version
Copy link
Collaborator

Choose a reason for hiding this comment

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

Hey @blunteshwar, I love that you're interested in tackling this workflow for us. I think it'll be a big improvement on how we can communicate some of these not-yet-ready for production releases to our consumers.

I wanted to mention a few things here that could help frame your work.

  1. Changesets has workflows for both pre-releases (alphas, betas, release candidates) as well as snapshots (timestamped one-off releases, "canary" or "nightly" releases). It looks like you might be combining both of those concepts here, but perhaps you intended to only focus on "snapshot" releases.
  2. Based on the docs links in the first point, depending on which type you choose, you might not need to perform the steps here to reason about the current and next version numbers. Especially if you decide that you want to use the snapshot workflow because it's all based on a timestamp which will always be incrementally created.
  3. If you want a pre-release instead of a snapshot, I'm pretty sure we can still lean on Changesets to handle the incremental numbering, but we can have a conversation about that if necessary. It's slightly more involved, but the preferred "Changesets way" of doing this involves branching.
  4. Finally, it is possible to get a little creative with GitHub Actions and Changesets by doing something similar to what we've done in Spectrum CSS or what Garth has done in Spectrum Tokens. This approach allows authorized repo contributors to publish snapshots via the GitHub Actions "run workflow" UI, without any CI or CLI needed.

Lots of possibilities with this tool! Please reach out to me, Cassondra, or Garth if you'd like to talk through this a bit more.

Copy link
Collaborator

Choose a reason for hiding this comment

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

This is what it looks like in the "run workflow UI"
Screenshot 2024-09-04 at 4 06 00 PM

And this is what it looks like on npm after that workflow completes
spectrum-css_page-_npm

LATEST_BETA=$(npm view @spectrum-web-components/bundle --tag beta version || echo "none")
echo "Latest beta: $LATEST_BETA"

if [[ $LATEST_BETA == *beta* ]]; then
# Extract beta number
BETA_NUMBER=$(echo $LATEST_BETA | grep -oP 'beta\.\K\d+')
# Increment the beta number
NEXT_BETA_NUMBER=$((BETA_NUMBER + 1))
else
# Start with beta.0 if no beta version exists
NEXT_BETA_NUMBER=0
fi

echo "Next beta number: $NEXT_BETA_NUMBER"
echo "next_beta_number=$NEXT_BETA_NUMBER" >> $GITHUB_OUTPUT

- name: Update package versions for beta release
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
NEXT_BETA_NUMBER: ${{ steps.version-info.outputs.next_beta_number }}
run: |
yarn changeset pre enter beta
yarn changeset pre enter beta.$NEXT_BETA_NUMBER
# Apply the changeset with specific beta tag
yarn changeset version
yarn lint:versions --fix
Expand All @@ -43,6 +64,7 @@ jobs:
run: |
git add .
git commit -am "chore: publish beta version"
yarn changeset pre exit
yarn prepublishOnly
yarn changeset publish --no-git-tag
yarn changeset publish --no-git-tag --tag beta
git reset --hard HEAD^
2 changes: 1 addition & 1 deletion package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,7 +22,7 @@
"build:ts:watch": "wireit",
"build:types": "wireit",
"build:watch": "wireit",
"changeset-snapshot-publish": "yarn prepublishOnly && yarn changeset version --snapshot && yarn lint:versions --fix && yarn update-version && yarn changeset publish --no-git-tag --tag snapshot",
"changeset-snapshot-publish": "yarn prepublishOnly && yarn changeset version --snapshot ${1} && yarn lint:versions --fix && yarn update-version && yarn changeset publish --no-git-tag --tag snapshot",
Copy link
Collaborator

Choose a reason for hiding this comment

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

Just as a heads up, this kind of positional parameter does not translate well across operating systems. The most cross-system way to pass variables to commands is via a node script using yargs to read in from the command line.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I appreciate your feedback about cross-platform parameter handling. You raise a valid point about positional parameters potentially causing issues across different operating systems.
While I agree that a Node script with yargs would be the most robust cross-platform solution, I believe this approach should work well for our current needs because:

  • Modern shells on macOS, Linux, and Windows (with appropriate tools) do support this type of parameter substitution
  • The Yarn/npm CLI handles these parameters consistently across platforms
  • This is specifically for snapshot releases, which we'll primarily be using for testing purposes
  • The implementation keeps all our command logic centralized in package.json
    The approach is straightforward and avoids the overhead of creating and maintaining separate script files
    Since this is just for snapshot/test releases rather than production deployments, the simplicity of this approach seems appropriate for our needs. If we encounter any compatibility issues, I'll certainly reconsider implementing a proper Node script solution. Thank you for the helpful suggestion!

Copy link
Collaborator

Choose a reason for hiding this comment

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

That all makes great sense! Thanks for outlining some of the background you did to validate this. This is only meant to be run in CI, is that correct? If we have anyone on a unique set-up, can we ask them to validate this locally if there's a chance it might need to be run manually?

"changeset-publish": "yarn prepublishOnly && yarn changeset version && yarn install && yarn lint:versions --fix && yarn update-version && yarn changeset publish --no-git-tag && yarn push-to-remote && yarn create-git-tag && yarn postpublish",
"update-version": "node ./tasks/update-version.js",
"chromatic": "chromatic --build-script-name storybook:build # note that --project-token must be set in your env variables",
Expand Down
Loading