tldraw/.github/workflows/publish-vscode-extension.yml

43 lines
947 B
YAML
Raw Normal View History

Set up automatic VS Code publishing (#3905) When pushing to production branch we now also package and publish a new version of the VS Code extension. We get the last version from VS Code marketplace and update the package.json with that version. We don't commit that to the repo though (see the discussion below). I added `VSCE_PAT` secret (my own personal access token from the dev.azure.com), which will expire in 1 year. This is used when running the publish command. Some more info here: - [Publishing from CI](https://code.visualstudio.com/api/working-with-extensions/continuous-integration#github-actions) - Publishing uses `VSCE_PAT` env variable ![image](https://github.com/tldraw/tldraw/assets/2523721/df971c57-5197-4525-bc58-d50dd4bd8f3c) ### 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. - [x] `vs code` — Changes to the vscode plugin - [ ] `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 ### Release Notes - Automate publishing of the VS Code extension.
2024-06-17 14:14:42 +00:00
name: Publish VS Code Extension
on:
push:
branches:
Do a pre-release of the VS code extension for merges to main. (#3957) VS Code extension can do [pre-releases](https://code.visualstudio.com/api/working-with-extensions/publishing-extension#prerelease-extensions). This would make it easier to test unreleased version of the extension (thanks @ds300 [for the suggestion](https://github.com/tldraw/tldraw/pull/3905#pullrequestreview-2122897351)) Tried the pre-release option manually, to see how it works: https://github.com/tldraw/tldraw/assets/2523721/880fe0a2-3f29-405b-9862-b30594cf5334 There's a drawback in that we need to update version even for pre-releases as they do not support other versioning schemes atm. I decided to go with patch versions for pre-releases and minor versions for regular releases. Feels like a better UX than having a really high patch number due to bumping it on every PR. > We only support major.minor.patch for extension versions, semver pre-release tags are not supported. So, if you publish a major.minor.patch-tag release to the Marketplace, it will be treated as major.minor.patch, and the tag will be ignored. Versions must be different between pre-release and regular releases. That is, if 1.2.3 is uploaded as a pre-release, the next regular release must be uploaded with a distinct version, such as 1.2.4. Full semver support will be available in the future. ### 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. - [x] `vs code` — Changes to the vscode plugin - [ ] `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 ### Release Notes - Release a pre-release when we merge changes to main.
2024-06-26 07:23:25 +00:00
- main
Set up automatic VS Code publishing (#3905) When pushing to production branch we now also package and publish a new version of the VS Code extension. We get the last version from VS Code marketplace and update the package.json with that version. We don't commit that to the repo though (see the discussion below). I added `VSCE_PAT` secret (my own personal access token from the dev.azure.com), which will expire in 1 year. This is used when running the publish command. Some more info here: - [Publishing from CI](https://code.visualstudio.com/api/working-with-extensions/continuous-integration#github-actions) - Publishing uses `VSCE_PAT` env variable ![image](https://github.com/tldraw/tldraw/assets/2523721/df971c57-5197-4525-bc58-d50dd4bd8f3c) ### 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. - [x] `vs code` — Changes to the vscode plugin - [ ] `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 ### Release Notes - Automate publishing of the VS Code extension.
2024-06-17 14:14:42 +00:00
- production
env:
CI: 1
PRINT_GITHUB_ANNOTATIONS: 1
defaults:
run:
shell: bash
jobs:
publish:
Set up automatic VS Code publishing (#3905) When pushing to production branch we now also package and publish a new version of the VS Code extension. We get the last version from VS Code marketplace and update the package.json with that version. We don't commit that to the repo though (see the discussion below). I added `VSCE_PAT` secret (my own personal access token from the dev.azure.com), which will expire in 1 year. This is used when running the publish command. Some more info here: - [Publishing from CI](https://code.visualstudio.com/api/working-with-extensions/continuous-integration#github-actions) - Publishing uses `VSCE_PAT` env variable ![image](https://github.com/tldraw/tldraw/assets/2523721/df971c57-5197-4525-bc58-d50dd4bd8f3c) ### 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. - [x] `vs code` — Changes to the vscode plugin - [ ] `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 ### Release Notes - Automate publishing of the VS Code extension.
2024-06-17 14:14:42 +00:00
name: Publish VS Code Extension
environment: vsce publish
Set up automatic VS Code publishing (#3905) When pushing to production branch we now also package and publish a new version of the VS Code extension. We get the last version from VS Code marketplace and update the package.json with that version. We don't commit that to the repo though (see the discussion below). I added `VSCE_PAT` secret (my own personal access token from the dev.azure.com), which will expire in 1 year. This is used when running the publish command. Some more info here: - [Publishing from CI](https://code.visualstudio.com/api/working-with-extensions/continuous-integration#github-actions) - Publishing uses `VSCE_PAT` env variable ![image](https://github.com/tldraw/tldraw/assets/2523721/df971c57-5197-4525-bc58-d50dd4bd8f3c) ### 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. - [x] `vs code` — Changes to the vscode plugin - [ ] `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 ### Release Notes - Automate publishing of the VS Code extension.
2024-06-17 14:14:42 +00:00
timeout-minutes: 15
runs-on: ubuntu-latest-16-cores-open
steps:
- name: Check out code
uses: actions/checkout@v3
with:
submodules: true
- uses: ./.github/actions/setup
- name: Build types
run: yarn build-types
- name: Get extension info from the marketplace
working-directory: 'apps/vscode/extension'
run: yarn get-info
- name: Publish extension
run: yarn tsx ./scripts/publish-vscode-extension.ts
env:
VSCE_PAT: ${{ secrets.VSCE_PAT }}
Do a pre-release of the VS code extension for merges to main. (#3957) VS Code extension can do [pre-releases](https://code.visualstudio.com/api/working-with-extensions/publishing-extension#prerelease-extensions). This would make it easier to test unreleased version of the extension (thanks @ds300 [for the suggestion](https://github.com/tldraw/tldraw/pull/3905#pullrequestreview-2122897351)) Tried the pre-release option manually, to see how it works: https://github.com/tldraw/tldraw/assets/2523721/880fe0a2-3f29-405b-9862-b30594cf5334 There's a drawback in that we need to update version even for pre-releases as they do not support other versioning schemes atm. I decided to go with patch versions for pre-releases and minor versions for regular releases. Feels like a better UX than having a really high patch number due to bumping it on every PR. > We only support major.minor.patch for extension versions, semver pre-release tags are not supported. So, if you publish a major.minor.patch-tag release to the Marketplace, it will be treated as major.minor.patch, and the tag will be ignored. Versions must be different between pre-release and regular releases. That is, if 1.2.3 is uploaded as a pre-release, the next regular release must be uploaded with a distinct version, such as 1.2.4. Full semver support will be available in the future. ### 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. - [x] `vs code` — Changes to the vscode plugin - [ ] `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 ### Release Notes - Release a pre-release when we merge changes to main.
2024-06-26 07:23:25 +00:00
TLDRAW_ENV: ${{ (github.ref == 'refs/heads/production' && 'production') || (github.ref == 'refs/heads/main' && 'staging') }}