feat(refactor): release test package for PRs

[nrjdalal]

1. feat(refactor): release test package for PRs

• minimize LOC while adding PR support, and easier to understand code
• now repository owner can release "test" package by commenting "release" on any PR
  • why? to reduce the risk of merging, not working, unwanted or malicious code
  • format 0.0.0-commitSha e.g. 0.0.0-7c34d29 with tag test
  • why by commenting? only the package that deems fit by the owner, but to be tested by submitter or owner are released by trigger word only, to not to build packages for every PR and commit that comes, users commenting release won't release any packages

2. recommendation (not included in PR)

• enables comment and status update on release
• via adding following condition, you need not have two workflows, as it releases "latest" tag on package.json version change otherwise "canary" as usual
  • updating 1.2.3 to 1.2.4 will release new latest package
• also enable the ability to create new tags like 1.1.1-something.0 will release the version with something tag

if [[ $GITHUB_EVENT_NAME == 'issue_comment' ]]; then
  TAG="test"
  RELEASE_VERSION="0.0.0-$(openssl rand -hex 7)"
+ elif [[ $PACKAGE_VERSION != $LATEST_VERSION ]]; then
+  RELEASE_VERSION=$PACKAGE_VERSION
+  HAS_TAG=$(echo $PACKAGE_VERSION | grep -o '[a-zA-Z]*' | head -n 1)
+  TAG=$([[ -n "$HAS_TAG" ]] && echo $HAS_TAG || echo "latest")
else
  TAG="canary"
  RELEASE_VERSION=$(bunx semver $LATEST_VERSION -i minor)
  TAGGED_VERSION=$(echo $VERSIONS | bunx json $TAG)
  RELEASE_VERSION=$([[ $TAGGED_VERSION == $RELEASE_VERSION* ]] && bunx semver $TAGGED_VERSION -i prerelease || echo $RELEASE_VERSION-$TAG.0)
fi

[Wombosvideo]

I saw in another repository that they used labels on GitHub to mark a pull-request as a release candidate. Instead of adding a comment to the PR, they add a label preview or similar to tell the pipeline that the push to this PR should be released as a test package (or deployed as a preview page in their case).

Using the label approach, all future pushes to this PR are automatically built and released on NPM as a test package. One disadvantage I see with this is that it follows the "once trusted, always trust" principle, which opens the door for malicious pushes after gaining the repo maintainer's trust. If I manage to make some time to further think about how the best implementation of a feature like this would look like, I'll let you know and be happy to discuss it with you. For now, I will keep this PR open, so I know I have to work on it.

[nrjdalal]

sure why not, you do you, keep releasing awesomeness