From 9607432b0a37f698c1f2b16079e55d820ef2e59f Mon Sep 17 00:00:00 2001 From: Dmitry Prudnikov Date: Mon, 31 Aug 2026 18:18:27 +0300 Subject: [PATCH 1/3] fix(ci): drop the uv flags that block every release Two flags were added to the uv steps and both break the release pull request, which is the one that must not be blocked. --no-build refuses to build a source distribution, and this workspace's own three packages are exactly that. It passed while the runner cache held a wheel for the version in the lock, and fails the moment that version moves, which is what a release does. On the release branch it reports "Building source distributions for coordinode is disabled" and every job stops before its real work. --locked fails when uv.lock disagrees with pyproject, and the release bumps the version in pyproject without regenerating the lock, so it disagrees by construction. With --no-build removed, the same branch then reports "the lockfile needs to be updated". Both were reproduced against that branch with a cold cache, and plain `uv sync --all-packages` was confirmed to install, generate the stubs and run the suite there. The comment left in place records what each flag does and what would have to change before either comes back: the release has to update the lock first. --- .github/workflows/ci.yml | 43 +++++++++++++++++++++------------------- 1 file changed, 23 insertions(+), 20 deletions(-) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index d5f8522..1f0b8b0 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -16,21 +16,24 @@ jobs: with: python-version: "3.11" - # --locked fails the job when uv.lock does not match pyproject, so CI - # resolves exactly what a developer resolved rather than picking up a - # newer release mid-run. --no-build installs from wheels only, which - # keeps a dependency's setup.py from executing on the runner. + # Plain `uv sync`, deliberately. Two flags were tried here and both break + # the release, which is the one pull request that must not be blocked: # - # The editable workspace members install regardless: --no-build refuses - # source distributions of dependencies, not a local editable install. - # Verified both ways, since the flag reads as though it would block them: - # a sync with an empty UV_CACHE_DIR into a fresh environment installs - # coordinode, langchain-coordinode and llama-index-graph-stores-coordinode - # and imports them, and every job below has run green with the flag on a - # clean runner. Remove it only with evidence, not on the wording. - - run: uv sync --locked --no-build - - run: uv run --locked --no-build ruff check coordinode/ langchain-coordinode/ llama-index-coordinode/ tests/ - - run: uv run --locked --no-build ruff format --check coordinode/ langchain-coordinode/ llama-index-coordinode/ tests/ + # --no-build refuses to build a source distribution, and this + # workspace's own three packages are exactly that. It + # passes while a cache holds a wheel for the version in + # the lock and fails the moment that version moves. + # --locked fails when uv.lock disagrees with pyproject, and the + # release bumps the version in pyproject without + # regenerating the lock, so it disagrees by construction. + # + # Both were verified against the release branch: --no-build reports + # "Building source distributions for coordinode is disabled", and + # --locked alone reports "the lockfile needs to be updated". Do not add + # either back without first making the release update the lock. + - run: uv sync + - run: uv run ruff check coordinode/ langchain-coordinode/ llama-index-coordinode/ tests/ + - run: uv run ruff format --check coordinode/ langchain-coordinode/ llama-index-coordinode/ tests/ test: name: Test (Python ${{ matrix.python-version }}) @@ -49,13 +52,13 @@ jobs: python-version: ${{ matrix.python-version }} - name: Install dependencies - run: uv sync --locked --no-build --all-packages + run: uv sync --all-packages - name: Generate proto stubs - run: uv run --locked --no-build make proto + run: uv run make proto - name: Unit tests - run: uv run --locked --no-build pytest tests/unit/ -v + run: uv run pytest tests/unit/ -v build-embedded: name: Build embedded (CI check) @@ -159,10 +162,10 @@ jobs: - name: Install + generate proto run: | - uv sync --locked --no-build --all-packages - uv run --locked --no-build make proto + uv sync --all-packages + uv run make proto - name: Integration tests env: COORDINODE_ADDR: "localhost:7080" - run: uv run --locked --no-build pytest tests/integration/ -v --timeout=30 + run: uv run pytest tests/integration/ -v --timeout=30 From de9019ffc4ada13343c6ab932e31927b4fcc8745 Mon Sep 17 00:00:00 2001 From: Dmitry Prudnikov Date: Mon, 31 Aug 2026 18:31:42 +0300 Subject: [PATCH 2/3] docs(ci): record the real reason both uv flags fail The comment said `--no-build` held only while a cache carried a wheel for the locked version. That was a guess and it is wrong. Measured on the release branch with a cold cache: with `uv.lock` regenerated so it names the new version, both `--no-build` and `--locked` pass there. Both fail only while the lock still names the old one. So the two flags have a single cause, not two: the release bumps the version in pyproject.toml and leaves the lock behind, forcing a re-resolve. `--locked` refuses the mismatch; `--no-build` refuses the build that re-resolving this workspace's own source packages requires. The comment now says that, states separately what restoring each flag would take, and records why fresh resolution on a pull request is wanted in the first place: a dependency that publishes a breaking release fails here, on a pull request, rather than after the merge that pins it. Also drops three em-dashes from earlier comments in the same file. --- .github/workflows/ci.yml | 38 ++++++++++++++++++++++---------------- 1 file changed, 22 insertions(+), 16 deletions(-) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index 1f0b8b0..88c74e6 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -16,21 +16,27 @@ jobs: with: python-version: "3.11" - # Plain `uv sync`, deliberately. Two flags were tried here and both break - # the release, which is the one pull request that must not be blocked: + # Plain `uv sync`, deliberately, on two counts. # - # --no-build refuses to build a source distribution, and this - # workspace's own three packages are exactly that. It - # passes while a cache holds a wheel for the version in - # the lock and fails the moment that version moves. - # --locked fails when uv.lock disagrees with pyproject, and the - # release bumps the version in pyproject without - # regenerating the lock, so it disagrees by construction. + # Resolving fresh on a pull request is wanted here, not merely tolerated: + # a dependency that publishes a breaking release fails these jobs, on a + # pull request, rather than after the merge that would have pinned it. # - # Both were verified against the release branch: --no-build reports - # "Building source distributions for coordinode is disabled", and - # --locked alone reports "the lockfile needs to be updated". Do not add - # either back without first making the release update the lock. + # The two flags tried here also break the release, and for one shared + # reason: the release bumps the version in pyproject.toml and leaves + # uv.lock naming the old one, so uv has to re-resolve. + # + # --locked fails on exactly that mismatch, reporting that the + # lockfile needs to be updated. + # --no-build fails because re-resolving means building this + # workspace's own three packages, which are source rather + # than wheels: "Building source distributions for + # coordinode is disabled". + # + # Verified on the release branch with a cold cache: both fail there, and + # both pass on that same branch once uv.lock carries the new version. So + # restoring either one means first making the release regenerate the + # lock, and even then it gives up the fresh resolution described above. - run: uv sync - run: uv run ruff check coordinode/ langchain-coordinode/ llama-index-coordinode/ tests/ - run: uv run ruff format --check coordinode/ langchain-coordinode/ llama-index-coordinode/ tests/ @@ -86,7 +92,7 @@ jobs: - name: Install wheel + run embedded tests # The main `test` job skips coordinode_embedded with importorskip # because that runner doesn't build the wheel. This job has the - # wheel — install it and run the embedded tests here, then assert + # wheel, so install it and run the embedded tests here, then assert # nothing was skipped (a skip with the wheel installed means a # broken manylinux glibc / missing numpy / etc., not the expected # "no wheel" condition). @@ -119,7 +125,7 @@ jobs: exit 1 fi if ! echo "$OUTPUT" | grep -qE '=+ [0-9]+ passed'; then - echo "::error::No tests passed — the module was likely not collected" + echo "::error::No tests passed; the module was likely not collected" exit 1 fi @@ -154,7 +160,7 @@ jobs: echo "coordinode is ready (attempt $i)" exit 0 fi - echo "Attempt $i/30 — not ready yet, sleeping 5s..." + echo "Attempt $i/30, not ready yet, sleeping 5s..." sleep 5 done echo "Error: coordinode did not become healthy after 150s" >&2 From 29d35bd8fc8d9b36b2805a41b462670f166d61a1 Mon Sep 17 00:00:00 2001 From: Dmitry Prudnikov Date: Mon, 31 Aug 2026 18:43:57 +0300 Subject: [PATCH 3/3] docs(ci): scope the fresh-resolution claim to when it happens The comment said a dependency publishing a breaking release would fail these jobs. It would not. Measured on main with a cold cache: `uv sync` leaves uv.lock untouched and installs the locked versions whenever the lock already satisfies pyproject.toml, so an ordinary pull request tests exactly what is pinned. Fresh resolution happens only where pyproject moves without the lock: a dependency bump, or the release. There it is the behaviour we want, since uv resolves the new set and these jobs exercise it, where `--locked` would refuse to run and report a stale lock instead of saying whether the new version works. --- .github/workflows/ci.yml | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index 88c74e6..271c1f5 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -18,9 +18,14 @@ jobs: # Plain `uv sync`, deliberately, on two counts. # - # Resolving fresh on a pull request is wanted here, not merely tolerated: - # a dependency that publishes a breaking release fails these jobs, on a - # pull request, rather than after the merge that would have pinned it. + # Resolving fresh is wanted on the pull requests where it actually + # happens, which is not all of them. `uv sync` follows the committed lock + # while that lock satisfies pyproject.toml, so an ordinary pull request + # installs the locked versions. When a pull request moves dependency + # metadata without regenerating the lock, uv resolves the new set and + # these jobs exercise it. `--locked` would instead refuse to run and + # report that the lock needs updating, which says nothing about whether + # the new version works. # # The two flags tried here also break the release, and for one shared # reason: the release bumps the version in pyproject.toml and leaves