chore: fix semantic_release of workers-runtime-sdk package to update uv.lock file properly

[ryanking13]

Fixes a bug in our release configuration that the automated ci is not updating the uv.lock file.

I copied the build_command from the workers-py package:

workers-py/packages/cli/pyproject.toml

Lines 108 to 113 in 7c5179f

	build_command = """
	pip install uv
	python -m pip install -e .[build]
	uv lock --upgrade-package "$PACKAGE_NAME"
	git add uv.lock
	uv build

[ask-bonk]

I can see the diff clearly. The PR changes the build_command in packages/runtime-sdk/pyproject.toml to add uv lock and git add uv.lock steps, mirroring what's done in the CLI package. Let me compare the two build_command blocks more closely.

The CLI package (packages/cli/pyproject.toml:108-114) has:

pip install uv
python -m pip install -e .[build]
uv lock --upgrade-package "$PACKAGE_NAME"
git add uv.lock
uv build

The new runtime-sdk build_command (packages/runtime-sdk/pyproject.toml:91-96) has:

pip install uv
uv lock --upgrade-package "$PACKAGE_NAME"
git add uv.lock
uv build

The only difference is the missing python -m pip install -e .[build] line. The CLI package has this because it has a [project.optional-dependencies] build = ["uv ~= 0.5.23"] — the runtime-sdk package doesn't have such a dependency group, so omitting it is correct.

The $PACKAGE_NAME environment variable is a built-in from python-semantic-release that resolves to the package name. The uv lock command will update the lockfile for the specific package being released, and git add uv.lock stages it so it gets included in the release commit.

This is a straightforward and correct fix. The change is minimal, matches the pattern established by the CLI package (with the appropriate omission), and addresses the stated issue.

LGTM

github run