Add util postversion hook to repush major version tag #9
Comments
BackgroundThe idea is to create additional tags for users' convenience so they can point to the latest non-breaking changes without having to make dependency updates for every single minor/patch change. So they can do this and just get everything within the - name: Sync to ReadMe Micro
uses: readmeio/readme-micro@v2as opposed to this: - name: Sync to ReadMe Micro
uses: readmeio/readme-micro@v2.0.1How we're doing this in
|
|
oh nice. I was some GitHub actions that automatically handles this, in semver fashion. how do we feel about actions requiring actions? at least, there is some sense of peace in knowing the package will probably continue to be maintained without additional work on ReadMe's end. |
|
GitHub's registry doesn't follow semver the same way GitHub does this themselves with Footnotes
|
…17) | 🚥 Related to #9 and readmeio/micro#211 | | :---------------- | ## 🧰 Changes Adds the version number in the payload sent during Webhook events (e.g., <kbd>push</kbd>). The Micro UI then stores that in its DB to version check sync'd repos against the latest published version. ### Additional context The version is inferred from the `package.json` at the time of the release (`git tag && npm version && npm publish`) to the [`@readme/micro` npm package](https://www.npmjs.com/package/@readme/micro). Why? 1. [GitHub's `context`](https://docs.github.com/en/actions/learn-github-actions/contexts#github-context) is inconsistent between webhook event types. `github.action_repository` (e.g., <kbd>"readmeio/readme-micro"</kbd>) and `github.action_ref` (e.g., <kbd>"refs/tags/2.3.0"</kbd>) are not guaranteed to be in the response from every webhook type. 2. Bitbucket doesn't have a similar `context`. Getting the version would require additional boilerplate code to, for example, parse the version from the args passed, `process.argv`, where `micro` is invoked in the `bitbucket-pipelines.yml` file: <kbd>script: npx @readme/micro@v2</kbd>. ## 🧬 QA & Testing Run with debugging logs enabled. Ensure the version, without an `x`, appears as a string formatted as `[\d]+.[\d]+.[\d]+` (e.g., <kbd>"2.3.0"</kbd>). --------- Co-authored-by: Dom Harrington <domharrington@protonmail.com>
| 🚥 Fixes #9 | | :---------------- | ## 🧰 Changes GitHub Actions allows you to define a tag for an action to use that doesn't have to be a fully qualified semver version. This means we can publish v2.3.0 onto npm and then re-push that to v2 as a git tag. This means we dont have to prompt users to upgrade any time we push a non-breaking change. This is a pretty common pattern that GitHub does themselves, and we also do it in rdme too! So then instead of telling people to do this: ```yaml - name: GitHub Action uses: readmeio/readme-micro@v2.3.0 ``` We can just do this ```yaml - name: GitHub Action uses: readmeio/readme-micro@v2 ``` ## 🧬 QA & Testing If you run this: ```sh ./bin/set-major-version-tag.js $ git tag v2 -f -m 'Top-level tag pointing to 2.3.0' Updated tag 'v2' (was fc99ec6) ``` You'll see how it works. We've automatically wired this up to the [postversion](https://docs.npmjs.com/cli/v7/commands/npm-version#description) event which is after the new npm version has been created and the new git tag is present.
Grab this from @kanadgupta
The text was updated successfully, but these errors were encountered: