[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
|
|
|
import { Auto } from '@auto-it/core'
|
|
|
|
import fetch from 'cross-fetch'
|
|
|
|
import glob from 'glob'
|
|
|
|
import { assert } from 'node:console'
|
|
|
|
import { appendFileSync } from 'node:fs'
|
[docs] Sync docs deploy with npm deploy (#3153)
This PR makes it so that our docs deployment process is tied to, and
mirrors, the npm deployment process.
From here on:
- Commits to main get deployed to staging.tldraw.dev
- Commits to a special protected branch called `docs-production` get
deployed to www.tldraw.dev
- Whenever we create a new npm 'latest' release we reset the HEAD of
docs-production to point to the tagged commit for that release.
- If we make a docs change that we want to appear on tldraw.dev ASAP
without waiting for the next npm release, we'll have to follow the same
process as for creating a patch release i.e merge a cherry-pick PR
targeting the latest release branch e.g. `v2.0.x`. This will not cause
another npm patch release unless the cherry-picked changes touch source
files, e.g. updating TSDoc comments.
### Change Type
- [x] `docs` — Changes to the documentation, examples, or templates.
- [x] `tools` — Changes to infrastructure, CI, internal scripts,
debugging tools, etc.
2024-03-14 14:43:32 +00:00
|
|
|
import { didAnyPackageChange } from './lib/didAnyPackageChange'
|
[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
|
|
|
import { exec } from './lib/exec'
|
2024-03-12 14:53:57 +00:00
|
|
|
import { generateAutoRcFile } from './lib/labels'
|
[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
|
|
|
import { nicelog } from './lib/nicelog'
|
|
|
|
import { getLatestVersion, publish, setAllVersions } from './lib/publishing'
|
|
|
|
import { getAllWorkspacePackages } from './lib/workspace'
|
Uploading the static assets to R2 bucket (#3921)
Uploads all the folders inside `./assets` folder to a new R2 bucket
called `cdn`. Uses the package version as the prefix, so that we can
host multiple versions of the assets.
### Change Type
<!-- ❗ Please select a 'Scope' label ❗️ -->
- [ ] `sdk` — Changes the tldraw SDK
- [ ] `dotcom` — Changes the tldraw.com web app
- [ ] `docs` — Changes to the documentation, examples, or templates.
- [ ] `vs code` — Changes to the vscode plugin
- [x] `internal` — Does not affect user-facing stuff
<!-- ❗ Please select a 'Type' label ❗️ -->
- [ ] `bugfix` — Bug fix
- [ ] `feature` — New feature
- [ ] `improvement` — Improving existing features
- [ ] `chore` — Updating dependencies, other boring stuff
- [ ] `galaxy brain` — Architectural changes
- [ ] `tests` — Changes to any test code
- [x] `tools` — Changes to infrastructure, CI, internal scripts,
debugging tools, etc.
- [ ] `dunno` — I don't know
### Test Plan
1. Add a step-by-step description of how to test your PR here.
2.
- [ ] Unit Tests
- [ ] End to end tests
### Release Notes
- Upload our static assets (fonts, icons, embed-icons, translations) to
a R2 bucket so that we can move away from using unpkg and start using
our own cdn.
2024-06-14 12:25:42 +00:00
|
|
|
import { uploadStaticAssets } from './upload-static-assets'
|
[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
|
|
|
|
|
|
|
async function main() {
|
|
|
|
const huppyToken = process.env.HUPPY_TOKEN
|
|
|
|
assert(huppyToken && typeof huppyToken === 'string', 'HUPPY_ACCESS_KEY env var must be set')
|
|
|
|
|
|
|
|
const latestVersionInBranch = await getLatestVersion()
|
|
|
|
const latestVersionOnNpm = (await exec('npm', ['show', 'tldraw', 'version'])).trim()
|
|
|
|
|
|
|
|
const isLatestVersion = latestVersionInBranch.format() === latestVersionOnNpm
|
|
|
|
|
|
|
|
const nextVersion = latestVersionInBranch.inc('patch').format()
|
|
|
|
// check we're on the main branch on HEAD
|
|
|
|
const currentBranch = (await exec('git', ['rev-parse', '--abbrev-ref', 'HEAD'])).toString().trim()
|
|
|
|
if (currentBranch !== `v${latestVersionInBranch.major}.${latestVersionInBranch.minor}.x`) {
|
|
|
|
throw new Error('Branch name does not match expected format: v{major}.{minor}.x')
|
|
|
|
}
|
|
|
|
|
|
|
|
// we could probably do this a lot earlier in the yml file but 🤷♂️
|
2024-03-11 09:42:28 +00:00
|
|
|
await exec('git', ['fetch', 'origin', '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
|
|
|
const numberOfCommitsSinceBranch = Number(
|
2024-03-11 09:42:28 +00:00
|
|
|
(await exec('git', ['rev-list', '--count', `HEAD`, '^origin/main'])).toString().trim()
|
[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 (numberOfCommitsSinceBranch === 0) {
|
|
|
|
// Skip release if there are no commits since this branch was created during the initial release
|
|
|
|
// for this <major>.<minor> version.
|
|
|
|
nicelog('Initial push, skipping release')
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
[docs] Sync docs deploy with npm deploy (#3153)
This PR makes it so that our docs deployment process is tied to, and
mirrors, the npm deployment process.
From here on:
- Commits to main get deployed to staging.tldraw.dev
- Commits to a special protected branch called `docs-production` get
deployed to www.tldraw.dev
- Whenever we create a new npm 'latest' release we reset the HEAD of
docs-production to point to the tagged commit for that release.
- If we make a docs change that we want to appear on tldraw.dev ASAP
without waiting for the next npm release, we'll have to follow the same
process as for creating a patch release i.e merge a cherry-pick PR
targeting the latest release branch e.g. `v2.0.x`. This will not cause
another npm patch release unless the cherry-picked changes touch source
files, e.g. updating TSDoc comments.
### Change Type
- [x] `docs` — Changes to the documentation, examples, or templates.
- [x] `tools` — Changes to infrastructure, CI, internal scripts,
debugging tools, etc.
2024-03-14 14:43:32 +00:00
|
|
|
if (isLatestVersion) {
|
|
|
|
await exec('git', ['push', 'origin', `HEAD:docs-production`, '--force'])
|
|
|
|
}
|
|
|
|
|
|
|
|
// Skip releasing a new version if the package contents are identical.
|
|
|
|
// This may happen when cherry-picking docs-only changes.
|
|
|
|
if (!(await didAnyPackageChange())) {
|
|
|
|
nicelog('No packages have changed, skipping release')
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
2024-03-14 15:41:55 +00:00
|
|
|
if (process.env.GITHUB_OUTPUT) {
|
|
|
|
appendFileSync(process.env.GITHUB_OUTPUT, `is_latest_version=${isLatestVersion}\n`)
|
|
|
|
}
|
|
|
|
|
[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
|
|
|
nicelog('Releasing version', nextVersion)
|
|
|
|
|
|
|
|
await setAllVersions(nextVersion)
|
|
|
|
|
|
|
|
// stage the changes
|
|
|
|
const packageJsonFilesToAdd = []
|
|
|
|
for (const workspace of await getAllWorkspacePackages()) {
|
|
|
|
if (workspace.relativePath.startsWith('packages/')) {
|
|
|
|
packageJsonFilesToAdd.push(`${workspace.relativePath}/package.json`)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
const versionFilesToAdd = glob.sync('**/*/version.ts', {
|
|
|
|
ignore: ['node_modules/**'],
|
|
|
|
follow: false,
|
|
|
|
})
|
|
|
|
console.log('versionFilesToAdd', versionFilesToAdd)
|
|
|
|
await exec('git', [
|
|
|
|
'add',
|
|
|
|
'--update',
|
|
|
|
'lerna.json',
|
|
|
|
...packageJsonFilesToAdd,
|
|
|
|
...versionFilesToAdd,
|
|
|
|
])
|
|
|
|
|
|
|
|
const auto = new Auto({
|
|
|
|
plugins: ['npm'],
|
|
|
|
baseBranch: currentBranch,
|
|
|
|
owner: 'tldraw',
|
|
|
|
repo: 'tldraw',
|
|
|
|
verbose: true,
|
|
|
|
disableTsNode: true,
|
|
|
|
})
|
|
|
|
|
2024-03-12 14:53:57 +00:00
|
|
|
await generateAutoRcFile()
|
[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
|
|
|
await auto.loadConfig()
|
|
|
|
|
|
|
|
// this creates a new commit
|
|
|
|
await auto.changelog({
|
|
|
|
useVersion: nextVersion,
|
|
|
|
title: `v${nextVersion}`,
|
|
|
|
})
|
|
|
|
|
|
|
|
// create and push a new tag
|
|
|
|
await exec('git', ['tag', '-f', `v${nextVersion}`])
|
|
|
|
await exec('git', ['push', '--follow-tags'])
|
|
|
|
|
|
|
|
// create a release on github
|
|
|
|
await auto.runRelease({ useVersion: nextVersion })
|
|
|
|
|
Uploading the static assets to R2 bucket (#3921)
Uploads all the folders inside `./assets` folder to a new R2 bucket
called `cdn`. Uses the package version as the prefix, so that we can
host multiple versions of the assets.
### Change Type
<!-- ❗ Please select a 'Scope' label ❗️ -->
- [ ] `sdk` — Changes the tldraw SDK
- [ ] `dotcom` — Changes the tldraw.com web app
- [ ] `docs` — Changes to the documentation, examples, or templates.
- [ ] `vs code` — Changes to the vscode plugin
- [x] `internal` — Does not affect user-facing stuff
<!-- ❗ Please select a 'Type' label ❗️ -->
- [ ] `bugfix` — Bug fix
- [ ] `feature` — New feature
- [ ] `improvement` — Improving existing features
- [ ] `chore` — Updating dependencies, other boring stuff
- [ ] `galaxy brain` — Architectural changes
- [ ] `tests` — Changes to any test code
- [x] `tools` — Changes to infrastructure, CI, internal scripts,
debugging tools, etc.
- [ ] `dunno` — I don't know
### Test Plan
1. Add a step-by-step description of how to test your PR here.
2.
- [ ] Unit Tests
- [ ] End to end tests
### Release Notes
- Upload our static assets (fonts, icons, embed-icons, translations) to
a R2 bucket so that we can move away from using unpkg and start using
our own cdn.
2024-06-14 12:25:42 +00:00
|
|
|
await uploadStaticAssets(nextVersion)
|
|
|
|
|
[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 we're on the latest version, publish to npm under 'latest' tag.
|
|
|
|
// otherwise we don't want to overwrite the latest tag, so we publish under 'revision'.
|
|
|
|
// semver rules will still be respected because there's no prerelease tag in the version,
|
|
|
|
// so clients will get the updated version if they have a range like ^1.0.0
|
|
|
|
await publish(isLatestVersion ? 'latest' : 'revision')
|
|
|
|
|
|
|
|
if (isLatestVersion) {
|
|
|
|
nicelog('Notifying huppy of release...')
|
|
|
|
const huppyResponse = await fetch('https://tldraw-repo-sync.fly.dev/api/on-release', {
|
|
|
|
method: 'POST',
|
|
|
|
headers: {
|
|
|
|
'Content-Type': 'application/json',
|
|
|
|
},
|
|
|
|
body: JSON.stringify({ apiKey: huppyToken, tagToRelease: `v${nextVersion}`, canary: false }),
|
|
|
|
})
|
|
|
|
nicelog(
|
|
|
|
`huppy: [${huppyResponse.status} ${huppyResponse.statusText}] ${await huppyResponse.text()}`
|
|
|
|
)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
main()
|