add release workflow
Release / Version (push) Canceled after 0s
Release / CI (push) Canceled after 0s
Release / Prebuild (macos-13) (push) Canceled after 0s
Release / Prebuild (macos-latest) (push) Canceled after 0s
Release / Prebuild (ubuntu-24.04-arm) (push) Canceled after 0s
Release / Prebuild (ubuntu-latest) (push) Canceled after 0s
Release / Prebuild (windows-latest) (push) Canceled after 0s
Release / Tag and publish (push) Canceled after 0s

This commit is contained in:
danhanson committed 2026-09-16 16:05:32 -05:00
1 parent 13c774dedb
commit 99123289f7
4 files changed
+290

No files matched your search

+7
View File
@@ -74,6 +74,13 @@ to `grammar.js` or `src/scanner.c` is only half made until `parser-generate` has
committed alongside it. `tree-sitter test` compiles the parser itself, so a stale `src/` shows up as tests
that pass against the wrong grammar.
Pull requests run the corpus tests and every binding through `.github/workflows/ci.yml`. A release is a
version-bump commit on `main`: raise the version in `package.json` and in `tree-sitter.json`'s `metadata`,
run `npm run parser-generate`, and push. The workflow tags `v<version>`, publishes to npm with provenance
and prebuilt binaries for Linux, macOS and Windows, and attaches `tree-sitter-django.wasm` to the GitHub
release. Running the workflow by hand publishes the current version if npm does not have it yet,
which is how a release that failed part way through is retried.
## Queries
Five of the files in `queries/` are query files an editor loads: