Add version input to pin livekit-server release or commit#3
Add version input to pin livekit-server release or commit#3alan-george-lk wants to merge 6 commits into
Conversation
SDK e2e jobs can pass a release tag or livekit/livekit commit SHA so tests run against server features not yet in the latest release. macOS and commit pins build from source; Linux and Windows download release artifacts when a tag is given. Co-authored-by: Cursor <cursoragent@cursor.com>
Use the upstream action commit from livekit/dev-server-action#3 instead of the personal fork so the version input can be reviewed and shipped in-repo. Co-authored-by: Cursor <cursoragent@cursor.com>
Build from inside the cloned livekit checkout so Go resolves the module, and cover the version input path in CI. Co-authored-by: Cursor <cursoragent@cursor.com>
Support latest default, semver without v prefix, release validation, and expand CI to matrix-test tag, semver, and commit SHA pinning. Co-authored-by: Cursor <cursoragent@cursor.com>
| required: true | ||
| version: | ||
| description: | | ||
| livekit-server version to run: latest, a release tag (e.g. v1.13.3 or 1.13.3), |
There was a problem hiding this comment.
suggestion: Description should explicitly say latest is used if a tag isn't provided.
| github-token: ${{ github.token }} | ||
| version: a47e21b6cb945aabee88c98650366cef8cbf7a99 | ||
| config: | | ||
| enable_data_tracks: true |
There was a problem hiding this comment.
suggestion: Maybe demonstrate with a more generic config key—data tracks is always on now, and data blobs will soon be too. See config-sample.yaml
There was a problem hiding this comment.
Demonstrated with logging, and linked to the config sample
| if [[ "$ref" =~ ^v[0-9] ]]; then | ||
| gh release view "$ref" --repo livekit/livekit >/dev/null | ||
| if [ "${RUNNER_OS}" = "macOS" ]; then | ||
| echo "mode=source" >> "$GITHUB_OUTPUT" |
There was a problem hiding this comment.
suggestion(non-blocking): Since building from source can take significantly longer and impact workflow performance, it might be a good idea to communicate explicitly when this is being done. Maybe add a notice message for visibility?
|
note: See config-sample.yaml for available config keys supported by the LiveKit server. |
Emit workflow notices when source builds are required, clarify the version input description, and update README examples to use stable config keys. Co-authored-by: Cursor <cursoragent@cursor.com>
Summary
versioninput so CI jobs can pinlivekit-serverto a release tag orlivekit/livekitcommit SHA.configinput to control new/specific features.