tldraw/.github/workflows/publish-manual.yml

47 lines
1.6 KiB
YAML
Raw Normal View History

2023-04-21 16:06:21 +00:00
name: (Re)Publish public packages manually
# This only attempts to publish the public packages to npm.
# It does not bump the version, it does not update the changelogs, it does not create a github release.
[infra] Patch release scripting (#3072) This PR adds tooling to enable a PR-based workflow for publishing 'patch' releases. ### How releases currently work Quick recap of how the 'major' and 'minor' releases work: - You trigger them manually in the github actions UI - It only works on the `main` branch. - You select a mode: `'major'`, `'minor'`, or `'override'` with a specific version. The override option is mainly for transitioning in and out of prerelease mode, but potentially also skipping unlucky numbers like 13 if you're feeling superstitious 🧙🏼 - It bumps the version numbers in the `package.json` and `version.ts` files. - It compiles a changelog based on descriptions/titles from all the PRs that have gone in to `main`. - It tags the commit with the version number e.g. `v2.0.0` and pushes all the changes made to `main` (i.e. changelogs, version bumps and the tag) - It creates a github release, e.g. https://github.com/tldraw/tldraw/releases/tag/v2.0.0 - It deploys the packages to npm - It tells huppy bot about the release (for now-defunct purposes, we can remove that code later) - It triggers the template repo update workflow ### Introducing: Release Branches This PR adds one step into the above process: creating a 'release' branch. e.g. if it publishes a new version tagged `v2.1.0` it will also create a branch named `v2.1.x`. These branches are protected in the following ways: - Only huppy bot can create or delete them (ad-hoc admin overrides are, of course, still doable should the need arise) - Like `main` they can only be updated via pull request. The process to create a patch release becomes simple: 1. Checkout the `v<major>.<minor>.x` branch you want to create a patch release for. e.g. git fetch && git checkout v2.1.x 4. Branch off, e.g. git checkout -b david/my-patch-release 6. Cherry-pick any commits you need from `main` into your branch, resolving any conflicts if they arise. **important**: don't do new work here because it won't be merged back into `main` automatically. Fix the thing in `main` first and then cherry-pick, unless you're in a big rush or whatever. e.g. git cherry-pick abdeaf234 cde234d09 ab23af287 7. Push your new branch to github as normal and make a PR targeting the `v<major>.<minor>.x` branch. 8. Merge it. Congratulations, you just triggered a patch release build. ### What happens (differently) during a patch release build. ⚡ A key thing to understand here is that **this script allows us to deploy patch versions of _older_ major/minor releases**. This will happen when we have customers pinned to older versions and they need a quick bugfix but don't have time to upgrade to the latest due to some breaking change. This will also happen if we ever adopt a kind of 'LTS' release model. With that said, here's how things go down differently: - Firstly, the build happens automatically after the PR is merged, and you don't select 'major' or 'minor' or anything, it just does its thing. - It bumps the version numbers in the `package.json` files and the `version.ts` files but these changes stay within the release branch, they don't get propagated to `main` (nor should they). - It compiles a changelog entry featuring just your one PR's description/title, and also pushes this to the release branch (but not `main`). - It still tags the commit and creates a github release as normal. - It still deploys the packages to npm (obvs). HOWEVER it only uses the `latest` tag if this will indeed be the latest version of the public packages. Otherwise, if we're patching an older release, it uses the `revision` tag. Unfortunately it doesn't seem to be an option to deploy with _no_ tag, but using `revision` still allows version strings like `~2.0.0` to capture subsequent patch releases like `2.0.3`. - Similarly it _only_ notifies huppy bot and _only_ triggers the template repo update if the version being deployed is actually the latest version. I'm going to merge this now to test it out but I'd still appreciate reviews.
2024-03-05 16:05:22 +00:00
# Prevent more than one non-canary npm publishing job from running at the same time
concurrency:
group: npm-publish
2023-04-21 16:06:21 +00:00
# Package publishing is manually triggered on github actions dashboard
on: workflow_dispatch
jobs:
deploy:
name: '(Re)Publish public packages manually'
environment: npm deploy
timeout-minutes: 60
2023-04-21 16:18:25 +00:00
runs-on: ubuntu-latest-16-cores-open
2023-04-21 16:06:21 +00:00
[infra] Patch release scripting (#3072) This PR adds tooling to enable a PR-based workflow for publishing 'patch' releases. ### How releases currently work Quick recap of how the 'major' and 'minor' releases work: - You trigger them manually in the github actions UI - It only works on the `main` branch. - You select a mode: `'major'`, `'minor'`, or `'override'` with a specific version. The override option is mainly for transitioning in and out of prerelease mode, but potentially also skipping unlucky numbers like 13 if you're feeling superstitious 🧙🏼 - It bumps the version numbers in the `package.json` and `version.ts` files. - It compiles a changelog based on descriptions/titles from all the PRs that have gone in to `main`. - It tags the commit with the version number e.g. `v2.0.0` and pushes all the changes made to `main` (i.e. changelogs, version bumps and the tag) - It creates a github release, e.g. https://github.com/tldraw/tldraw/releases/tag/v2.0.0 - It deploys the packages to npm - It tells huppy bot about the release (for now-defunct purposes, we can remove that code later) - It triggers the template repo update workflow ### Introducing: Release Branches This PR adds one step into the above process: creating a 'release' branch. e.g. if it publishes a new version tagged `v2.1.0` it will also create a branch named `v2.1.x`. These branches are protected in the following ways: - Only huppy bot can create or delete them (ad-hoc admin overrides are, of course, still doable should the need arise) - Like `main` they can only be updated via pull request. The process to create a patch release becomes simple: 1. Checkout the `v<major>.<minor>.x` branch you want to create a patch release for. e.g. git fetch && git checkout v2.1.x 4. Branch off, e.g. git checkout -b david/my-patch-release 6. Cherry-pick any commits you need from `main` into your branch, resolving any conflicts if they arise. **important**: don't do new work here because it won't be merged back into `main` automatically. Fix the thing in `main` first and then cherry-pick, unless you're in a big rush or whatever. e.g. git cherry-pick abdeaf234 cde234d09 ab23af287 7. Push your new branch to github as normal and make a PR targeting the `v<major>.<minor>.x` branch. 8. Merge it. Congratulations, you just triggered a patch release build. ### What happens (differently) during a patch release build. ⚡ A key thing to understand here is that **this script allows us to deploy patch versions of _older_ major/minor releases**. This will happen when we have customers pinned to older versions and they need a quick bugfix but don't have time to upgrade to the latest due to some breaking change. This will also happen if we ever adopt a kind of 'LTS' release model. With that said, here's how things go down differently: - Firstly, the build happens automatically after the PR is merged, and you don't select 'major' or 'minor' or anything, it just does its thing. - It bumps the version numbers in the `package.json` files and the `version.ts` files but these changes stay within the release branch, they don't get propagated to `main` (nor should they). - It compiles a changelog entry featuring just your one PR's description/title, and also pushes this to the release branch (but not `main`). - It still tags the commit and creates a github release as normal. - It still deploys the packages to npm (obvs). HOWEVER it only uses the `latest` tag if this will indeed be the latest version of the public packages. Otherwise, if we're patching an older release, it uses the `revision` tag. Unfortunately it doesn't seem to be an option to deploy with _no_ tag, but using `revision` still allows version strings like `~2.0.0` to capture subsequent patch releases like `2.0.3`. - Similarly it _only_ notifies huppy bot and _only_ triggers the template repo update if the version being deployed is actually the latest version. I'm going to merge this now to test it out but I'd still appreciate reviews.
2024-03-05 16:05:22 +00:00
outputs:
is_latest_version: ${{ steps.publish_step.outputs.is_latest_version }}
2023-04-21 16:06:21 +00:00
steps:
- name: Check out code
2023-04-21 16:06:21 +00:00
uses: actions/checkout@v3
Bump Yarn to 4.0.2 and add version constraints (#2481) This PR bumps Yarn to 4.0.2, adds version constraints and fixes reported problems. Current constraints (per @ds300): 1. all dependencies (both prod and dev) should have consistent versions across the project 2. only the root `package.json` should have `packageManager` set Removed 54 packages due to deduplication. ### Change Type - [ ] `patch` — Bug fix - [ ] `minor` — New feature - [ ] `major` — Breaking change - [x] `dependencies` — Changes to package dependencies[^1] - [ ] `documentation` — Changes to the documentation only[^2] - [ ] `tests` — Changes to any test code only[^2] - [ ] `internal` — Any other changes that don't affect the published package[^2] - [ ] I don't know [^1]: publishes a `patch` release, for devDependencies use `internal` [^2]: will not publish a new version <details> <summary>An example of a report with a bunch of problems</summary> ``` ❯ yarn constraints ➤ Errors prefixed by '⚙' can be fixed by running yarn constraints --fix ├─ @tldraw/monorepo@workspace:. │ ├─ Conflict detected in constraint targeting devDependencies["@types/react"]; conflicting values are: │ │ ├─ '^18.2.47' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^18.2.33' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["@typescript-eslint/eslint-plugin"]; conflicting values are: │ │ ├─ '^5.57.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^5.10.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["@typescript-eslint/parser"]; conflicting values are: │ │ ├─ '^5.57.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^5.10.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["eslint"]; conflicting values are: │ │ ├─ '^8.37.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '8.36.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["eslint-config-prettier"]; conflicting values are: │ │ ├─ '^8.8.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^8.3.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["eslint-plugin-react"]; conflicting values are: │ │ ├─ '^7.32.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '7.28.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["prettier-plugin-organize-imports"]; conflicting values are: │ │ ├─ '^3.2.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^3.2.3' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["tsx"]; conflicting values are: │ │ ├─ '^3.12.7' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^4.0.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ └─ Conflict detected in constraint targeting devDependencies["typescript"]; conflicting values are: │ ├─ '^5.2.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ └─ '^5.0.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ @tldraw/docs@workspace:apps/docs │ ├─ Conflict detected in constraint targeting dependencies["@types/ws"]; conflicting values are: │ │ ├─ '^8.5.9' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^8.5.3' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["@vercel/analytics"]; conflicting values are: │ │ ├─ '^1.1.1' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^1.0.1' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["concurrently"]; conflicting values are: │ │ ├─ '^8.2.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ ├─ '^8.2.1' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '7.0.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["dotenv"]; conflicting values are: │ │ ├─ '^16.3.1' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^16.0.3' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["eslint"]; conflicting values are: │ │ ├─ '^8.37.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '8.36.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["eslint-config-next"]; conflicting values are: │ │ ├─ '13.2.4' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '12.2.5' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["next"]; conflicting values are: │ │ ├─ '^14.0.4' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^13.2.3' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["prettier-plugin-organize-imports"]; conflicting values are: │ │ ├─ '^3.2.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^3.2.3' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["react"]; conflicting values are: │ │ ├─ '18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["react-dom"]; conflicting values are: │ │ ├─ '18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["tsx"]; conflicting values are: │ │ ├─ '^3.12.7' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^4.0.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["typescript"]; conflicting values are: │ │ ├─ '^5.2.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^5.0.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["ws"]; conflicting values are: │ │ ├─ '^8.14.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ ├─ '^8.13.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^8.16.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ └─ ⚙ Invalid field packageManager; expected null, found 'yarn@3.5.0' │ ├─ dotcom@workspace:apps/dotcom │ ├─ Conflict detected in constraint targeting dependencies["@radix-ui/react-popover"]; conflicting values are: │ │ ├─ '1.0.6-rc.5' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^1.0.7' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["@vercel/analytics"]; conflicting values are: │ │ ├─ '^1.1.1' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^1.0.1' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["react"]; conflicting values are: │ │ ├─ '18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["react-dom"]; conflicting values are: │ │ ├─ '18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["react-router-dom"]; conflicting values are: │ │ ├─ '^6.17.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^6.9.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["@types/react"]; conflicting values are: │ │ ├─ '^18.2.47' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^18.2.33' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["dotenv"]; conflicting values are: │ │ ├─ '^16.3.1' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^16.0.3' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["vite"]; conflicting values are: │ │ ├─ '^5.0.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^4.3.4' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["ws"]; conflicting values are: │ │ ├─ '^8.14.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ ├─ '^8.13.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^8.16.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ └─ ⚙ Invalid field packageManager; expected null, found 'yarn@3.5.0' │ ├─ dotcom-asset-upload@workspace:apps/dotcom-asset-upload │ ├─ Conflict detected in constraint targeting dependencies["itty-router"]; conflicting values are: │ │ ├─ '^2.6.6' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^4.0.13' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["@types/ws"]; conflicting values are: │ │ ├─ '^8.5.9' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^8.5.3' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ └─ ⚙ Invalid field packageManager; expected null, found 'yarn@3.5.0' │ ├─ @tldraw/bookmark-extractor@workspace:apps/dotcom-bookmark-extractor │ ├─ Conflict detected in constraint targeting dependencies["tslib"]; conflicting values are: │ │ ├─ '^2.6.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^2.4.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["typescript"]; conflicting values are: │ │ ├─ '^5.2.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^5.0.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ └─ ⚙ Invalid field packageManager; expected null, found 'yarn@3.5.0' │ ├─ @tldraw/dotcom-worker@workspace:apps/dotcom-worker │ ├─ Conflict detected in constraint targeting dependencies["itty-router"]; conflicting values are: │ │ ├─ '^2.6.6' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^4.0.13' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["concurrently"]; conflicting values are: │ │ ├─ '^8.2.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ ├─ '^8.2.1' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '7.0.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["typescript"]; conflicting values are: │ │ ├─ '^5.2.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^5.0.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ └─ ⚙ Invalid field packageManager; expected null, found 'yarn@3.5.0' │ ├─ examples.tldraw.com@workspace:apps/examples │ ├─ Conflict detected in constraint targeting dependencies["@vercel/analytics"]; conflicting values are: │ │ ├─ '^1.1.1' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^1.0.1' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["react"]; conflicting values are: │ │ ├─ '18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["react-dom"]; conflicting values are: │ │ ├─ '18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["react-router-dom"]; conflicting values are: │ │ ├─ '^6.17.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^6.9.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["vite"]; conflicting values are: │ │ ├─ '^5.0.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^4.3.4' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["dotenv"]; conflicting values are: │ │ ├─ '^16.3.1' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^16.0.3' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ └─ ⚙ Invalid field packageManager; expected null, found 'yarn@3.5.0' │ ├─ huppy@workspace:apps/huppy │ ├─ Conflict detected in constraint targeting dependencies["next"]; conflicting values are: │ │ ├─ '^14.0.4' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^13.2.3' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["react"]; conflicting values are: │ │ ├─ '18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["react-dom"]; conflicting values are: │ │ ├─ '18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["eslint-config-next"]; conflicting values are: │ │ ├─ '13.2.4' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '12.2.5' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ └─ ⚙ Invalid field packageManager; expected null, found 'yarn@3.5.0' │ ├─ @tldraw/vscode-editor@workspace:apps/vscode/editor │ ├─ Conflict detected in constraint targeting devDependencies["@types/react"]; conflicting values are: │ │ ├─ '^18.2.47' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^18.2.33' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["concurrently"]; conflicting values are: │ │ ├─ '^8.2.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ ├─ '^8.2.1' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '7.0.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["dotenv"]; conflicting values are: │ │ ├─ '^16.3.1' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^16.0.3' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["react"]; conflicting values are: │ │ ├─ '18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["react-dom"]; conflicting values are: │ │ ├─ '18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^18.2.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["tslib"]; conflicting values are: │ │ ├─ '^2.6.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^2.4.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ └─ ⚙ Invalid field packageManager; expected null, found 'yarn@3.5.0' │ ├─ tldraw-vscode@workspace:apps/vscode/extension │ ├─ Conflict detected in constraint targeting devDependencies["@typescript-eslint/eslint-plugin"]; conflicting values are: │ │ ├─ '^5.57.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^5.10.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["@typescript-eslint/parser"]; conflicting values are: │ │ ├─ '^5.57.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^5.10.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["tslib"]; conflicting values are: │ │ ├─ '^2.6.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^2.4.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["tsx"]; conflicting values are: │ │ ├─ '^3.12.7' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^4.0.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ └─ ⚙ Invalid field packageManager; expected null, found 'yarn@3.5.0' │ ├─ config@workspace:config │ ├─ Conflict detected in constraint targeting dependencies["eslint-config-prettier"]; conflicting values are: │ │ ├─ '^8.8.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^8.3.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting dependencies["eslint-plugin-react"]; conflicting values are: │ │ ├─ '^7.32.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '7.28.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ └─ ⚙ Missing field packageManager; expected null │ ├─ @tldraw/assets@workspace:packages/assets │ └─ ⚙ Missing field packageManager; expected null │ ├─ @tldraw/editor@workspace:packages/editor │ ├─ Conflict detected in constraint targeting devDependencies["@testing-library/jest-dom"]; conflicting values are: │ │ ├─ '^5.16.5' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^5.14.1' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["jest-canvas-mock"]; conflicting values are: │ │ ├─ '^2.5.1' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^2.5.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["jest-environment-jsdom"]; conflicting values are: │ │ ├─ '^29.4.3' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^28.1.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ └─ ⚙ Invalid field packageManager; expected null, found 'yarn@3.5.0' │ ├─ @tldraw/state@workspace:packages/state │ ├─ Conflict detected in constraint targeting devDependencies["@types/react"]; conflicting values are: │ │ ├─ '^18.2.47' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^18.2.33' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ └─ ⚙ Invalid field packageManager; expected null, found 'yarn@3.5.0' │ ├─ @tldraw/store@workspace:packages/store │ └─ ⚙ Invalid field packageManager; expected null, found 'yarn@3.5.0' │ ├─ @tldraw/tldraw@workspace:packages/tldraw │ ├─ Conflict detected in constraint targeting dependencies["@radix-ui/react-popover"]; conflicting values are: │ │ ├─ '1.0.6-rc.5' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^1.0.7' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["@testing-library/jest-dom"]; conflicting values are: │ │ ├─ '^5.16.5' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^5.14.1' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["jest-canvas-mock"]; conflicting values are: │ │ ├─ '^2.5.1' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^2.5.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["jest-environment-jsdom"]; conflicting values are: │ │ ├─ '^29.4.3' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^28.1.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ └─ ⚙ Invalid field packageManager; expected null, found 'yarn@3.5.0' │ ├─ @tldraw/tlschema@workspace:packages/tlschema │ └─ ⚙ Invalid field packageManager; expected null, found 'yarn@3.5.0' │ ├─ @tldraw/tlsync@workspace:packages/tlsync │ ├─ Conflict detected in constraint targeting dependencies["ws"]; conflicting values are: │ │ ├─ '^8.14.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ ├─ '^8.13.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^8.16.0' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ ├─ Conflict detected in constraint targeting devDependencies["typescript"]; conflicting values are: │ │ ├─ '^5.2.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ │ └─ '^5.0.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ └─ ⚙ Invalid field packageManager; expected null, found 'yarn@3.5.0' │ ├─ @tldraw/utils@workspace:packages/utils │ └─ ⚙ Invalid field packageManager; expected null, found 'yarn@3.5.0' │ ├─ @tldraw/validate@workspace:packages/validate │ └─ ⚙ Invalid field packageManager; expected null, found 'yarn@3.5.0' │ └─ @tldraw/scripts@workspace:scripts ├─ Conflict detected in constraint targeting devDependencies["typescript"]; conflicting values are: │ ├─ '^5.2.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) │ └─ '^5.0.2' at enforceConsistentDependenciesAcrossTheProject (…/tldraw/yarn.config.cjs:14:15) └─ ⚙ Invalid field packageManager; expected null, found 'yarn@3.5.0' ``` </details>
2024-01-18 11:09:17 +00:00
- name: Run our setup
uses: ./.github/actions/setup
2023-04-21 16:06:21 +00:00
- name: Publish
[infra] Patch release scripting (#3072) This PR adds tooling to enable a PR-based workflow for publishing 'patch' releases. ### How releases currently work Quick recap of how the 'major' and 'minor' releases work: - You trigger them manually in the github actions UI - It only works on the `main` branch. - You select a mode: `'major'`, `'minor'`, or `'override'` with a specific version. The override option is mainly for transitioning in and out of prerelease mode, but potentially also skipping unlucky numbers like 13 if you're feeling superstitious 🧙🏼 - It bumps the version numbers in the `package.json` and `version.ts` files. - It compiles a changelog based on descriptions/titles from all the PRs that have gone in to `main`. - It tags the commit with the version number e.g. `v2.0.0` and pushes all the changes made to `main` (i.e. changelogs, version bumps and the tag) - It creates a github release, e.g. https://github.com/tldraw/tldraw/releases/tag/v2.0.0 - It deploys the packages to npm - It tells huppy bot about the release (for now-defunct purposes, we can remove that code later) - It triggers the template repo update workflow ### Introducing: Release Branches This PR adds one step into the above process: creating a 'release' branch. e.g. if it publishes a new version tagged `v2.1.0` it will also create a branch named `v2.1.x`. These branches are protected in the following ways: - Only huppy bot can create or delete them (ad-hoc admin overrides are, of course, still doable should the need arise) - Like `main` they can only be updated via pull request. The process to create a patch release becomes simple: 1. Checkout the `v<major>.<minor>.x` branch you want to create a patch release for. e.g. git fetch && git checkout v2.1.x 4. Branch off, e.g. git checkout -b david/my-patch-release 6. Cherry-pick any commits you need from `main` into your branch, resolving any conflicts if they arise. **important**: don't do new work here because it won't be merged back into `main` automatically. Fix the thing in `main` first and then cherry-pick, unless you're in a big rush or whatever. e.g. git cherry-pick abdeaf234 cde234d09 ab23af287 7. Push your new branch to github as normal and make a PR targeting the `v<major>.<minor>.x` branch. 8. Merge it. Congratulations, you just triggered a patch release build. ### What happens (differently) during a patch release build. ⚡ A key thing to understand here is that **this script allows us to deploy patch versions of _older_ major/minor releases**. This will happen when we have customers pinned to older versions and they need a quick bugfix but don't have time to upgrade to the latest due to some breaking change. This will also happen if we ever adopt a kind of 'LTS' release model. With that said, here's how things go down differently: - Firstly, the build happens automatically after the PR is merged, and you don't select 'major' or 'minor' or anything, it just does its thing. - It bumps the version numbers in the `package.json` files and the `version.ts` files but these changes stay within the release branch, they don't get propagated to `main` (nor should they). - It compiles a changelog entry featuring just your one PR's description/title, and also pushes this to the release branch (but not `main`). - It still tags the commit and creates a github release as normal. - It still deploys the packages to npm (obvs). HOWEVER it only uses the `latest` tag if this will indeed be the latest version of the public packages. Otherwise, if we're patching an older release, it uses the `revision` tag. Unfortunately it doesn't seem to be an option to deploy with _no_ tag, but using `revision` still allows version strings like `~2.0.0` to capture subsequent patch releases like `2.0.3`. - Similarly it _only_ notifies huppy bot and _only_ triggers the template repo update if the version being deployed is actually the latest version. I'm going to merge this now to test it out but I'd still appreciate reviews.
2024-03-05 16:05:22 +00:00
id: publish_step
2023-04-21 16:06:21 +00:00
run: yarn tsx ./scripts/publish-manual.ts
env:
GH_TOKEN: ${{ github.token }}
2023-04-21 16:06:21 +00:00
NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
R2_ACCESS_KEY_ID: ${{ secrets.R2_ACCESS_KEY_ID }}
R2_ACCESS_KEY_SECRET: ${{ secrets.R2_ACCESS_KEY_SECRET }}
TLDRAW_BEMO_URL: https://demo.tldraw.xyz
publish_templates:
name: Publishes code templates to separate repositories
uses: tldraw/tldraw/.github/workflows/publish-templates.yml@main
[infra] Patch release scripting (#3072) This PR adds tooling to enable a PR-based workflow for publishing 'patch' releases. ### How releases currently work Quick recap of how the 'major' and 'minor' releases work: - You trigger them manually in the github actions UI - It only works on the `main` branch. - You select a mode: `'major'`, `'minor'`, or `'override'` with a specific version. The override option is mainly for transitioning in and out of prerelease mode, but potentially also skipping unlucky numbers like 13 if you're feeling superstitious 🧙🏼 - It bumps the version numbers in the `package.json` and `version.ts` files. - It compiles a changelog based on descriptions/titles from all the PRs that have gone in to `main`. - It tags the commit with the version number e.g. `v2.0.0` and pushes all the changes made to `main` (i.e. changelogs, version bumps and the tag) - It creates a github release, e.g. https://github.com/tldraw/tldraw/releases/tag/v2.0.0 - It deploys the packages to npm - It tells huppy bot about the release (for now-defunct purposes, we can remove that code later) - It triggers the template repo update workflow ### Introducing: Release Branches This PR adds one step into the above process: creating a 'release' branch. e.g. if it publishes a new version tagged `v2.1.0` it will also create a branch named `v2.1.x`. These branches are protected in the following ways: - Only huppy bot can create or delete them (ad-hoc admin overrides are, of course, still doable should the need arise) - Like `main` they can only be updated via pull request. The process to create a patch release becomes simple: 1. Checkout the `v<major>.<minor>.x` branch you want to create a patch release for. e.g. git fetch && git checkout v2.1.x 4. Branch off, e.g. git checkout -b david/my-patch-release 6. Cherry-pick any commits you need from `main` into your branch, resolving any conflicts if they arise. **important**: don't do new work here because it won't be merged back into `main` automatically. Fix the thing in `main` first and then cherry-pick, unless you're in a big rush or whatever. e.g. git cherry-pick abdeaf234 cde234d09 ab23af287 7. Push your new branch to github as normal and make a PR targeting the `v<major>.<minor>.x` branch. 8. Merge it. Congratulations, you just triggered a patch release build. ### What happens (differently) during a patch release build. ⚡ A key thing to understand here is that **this script allows us to deploy patch versions of _older_ major/minor releases**. This will happen when we have customers pinned to older versions and they need a quick bugfix but don't have time to upgrade to the latest due to some breaking change. This will also happen if we ever adopt a kind of 'LTS' release model. With that said, here's how things go down differently: - Firstly, the build happens automatically after the PR is merged, and you don't select 'major' or 'minor' or anything, it just does its thing. - It bumps the version numbers in the `package.json` files and the `version.ts` files but these changes stay within the release branch, they don't get propagated to `main` (nor should they). - It compiles a changelog entry featuring just your one PR's description/title, and also pushes this to the release branch (but not `main`). - It still tags the commit and creates a github release as normal. - It still deploys the packages to npm (obvs). HOWEVER it only uses the `latest` tag if this will indeed be the latest version of the public packages. Otherwise, if we're patching an older release, it uses the `revision` tag. Unfortunately it doesn't seem to be an option to deploy with _no_ tag, but using `revision` still allows version strings like `~2.0.0` to capture subsequent patch releases like `2.0.3`. - Similarly it _only_ notifies huppy bot and _only_ triggers the template repo update if the version being deployed is actually the latest version. I'm going to merge this now to test it out but I'd still appreciate reviews.
2024-03-05 16:05:22 +00:00
if: ${{ needs.deploy.outputs.is_latest_version == 'true' }}
secrets:
VITE_TEMPLATE_REPO_SSH_DEPLOY_KEY: ${{ secrets.VITE_TEMPLATE_REPO_SSH_DEPLOY_KEY }}
NEXTJS_TEMPLATE_REPO_SSH_DEPLOY_KEY: ${{ secrets.NEXTJS_TEMPLATE_REPO_SSH_DEPLOY_KEY }}
[infra] Patch release scripting (#3072) This PR adds tooling to enable a PR-based workflow for publishing 'patch' releases. ### How releases currently work Quick recap of how the 'major' and 'minor' releases work: - You trigger them manually in the github actions UI - It only works on the `main` branch. - You select a mode: `'major'`, `'minor'`, or `'override'` with a specific version. The override option is mainly for transitioning in and out of prerelease mode, but potentially also skipping unlucky numbers like 13 if you're feeling superstitious 🧙🏼 - It bumps the version numbers in the `package.json` and `version.ts` files. - It compiles a changelog based on descriptions/titles from all the PRs that have gone in to `main`. - It tags the commit with the version number e.g. `v2.0.0` and pushes all the changes made to `main` (i.e. changelogs, version bumps and the tag) - It creates a github release, e.g. https://github.com/tldraw/tldraw/releases/tag/v2.0.0 - It deploys the packages to npm - It tells huppy bot about the release (for now-defunct purposes, we can remove that code later) - It triggers the template repo update workflow ### Introducing: Release Branches This PR adds one step into the above process: creating a 'release' branch. e.g. if it publishes a new version tagged `v2.1.0` it will also create a branch named `v2.1.x`. These branches are protected in the following ways: - Only huppy bot can create or delete them (ad-hoc admin overrides are, of course, still doable should the need arise) - Like `main` they can only be updated via pull request. The process to create a patch release becomes simple: 1. Checkout the `v<major>.<minor>.x` branch you want to create a patch release for. e.g. git fetch && git checkout v2.1.x 4. Branch off, e.g. git checkout -b david/my-patch-release 6. Cherry-pick any commits you need from `main` into your branch, resolving any conflicts if they arise. **important**: don't do new work here because it won't be merged back into `main` automatically. Fix the thing in `main` first and then cherry-pick, unless you're in a big rush or whatever. e.g. git cherry-pick abdeaf234 cde234d09 ab23af287 7. Push your new branch to github as normal and make a PR targeting the `v<major>.<minor>.x` branch. 8. Merge it. Congratulations, you just triggered a patch release build. ### What happens (differently) during a patch release build. ⚡ A key thing to understand here is that **this script allows us to deploy patch versions of _older_ major/minor releases**. This will happen when we have customers pinned to older versions and they need a quick bugfix but don't have time to upgrade to the latest due to some breaking change. This will also happen if we ever adopt a kind of 'LTS' release model. With that said, here's how things go down differently: - Firstly, the build happens automatically after the PR is merged, and you don't select 'major' or 'minor' or anything, it just does its thing. - It bumps the version numbers in the `package.json` files and the `version.ts` files but these changes stay within the release branch, they don't get propagated to `main` (nor should they). - It compiles a changelog entry featuring just your one PR's description/title, and also pushes this to the release branch (but not `main`). - It still tags the commit and creates a github release as normal. - It still deploys the packages to npm (obvs). HOWEVER it only uses the `latest` tag if this will indeed be the latest version of the public packages. Otherwise, if we're patching an older release, it uses the `revision` tag. Unfortunately it doesn't seem to be an option to deploy with _no_ tag, but using `revision` still allows version strings like `~2.0.0` to capture subsequent patch releases like `2.0.3`. - Similarly it _only_ notifies huppy bot and _only_ triggers the template repo update if the version being deployed is actually the latest version. I'm going to merge this now to test it out but I'd still appreciate reviews.
2024-03-05 16:05:22 +00:00
needs: deploy