Skip to content

fix: build pipeline - #72

Merged
FreezeManny merged 1 commit into
mainfrom
71-fix-build-pipeline
Aug 19, 2026
Merged

fix: build pipeline#72
FreezeManny merged 1 commit into
mainfrom
71-fix-build-pipeline

Conversation

@FreezeManny

Copy link
Copy Markdown
Owner

No description provided.

@FreezeManny FreezeManny linked an issue Aug 19, 2026 that may be closed by this pull request
@FreezeManny
FreezeManny merged commit c8b9de6 into main Aug 19, 2026
2 checks passed
FreezeManny added a commit that referenced this pull request Aug 19, 2026
Closes #73.

## Problem

`uv sync --locked` fails on every release PR (e.g. #70):

```
error: The lockfile at `uv.lock` needs to be updated, but `--locked` was provided.
```

uv records a `version` for the root package in `uv.lock` only when
`pyproject.toml` states one statically. release-please bumps
`pyproject.toml` and leaves the lock behind, so the two disagree.

The blast radius is wider than the release PR: `Test` runs on
`pull_request`, so once a release PR merges, the stale lock lands on
main and **every subsequent PR** fails the same way. `Docs` (`uv sync
--locked --group docs`, on `release: published`) would fail on the
release itself. `Publish` is unaffected — it only runs `uv build`.

## Fix

Make the version dynamic. With `dynamic = ["version"]`, uv omits the
field from the lock entirely, so a release bump cannot desynchronise it
and `--locked` stays strict for the dependabot PRs it was added for.

| root version | after a 0.9.1 → 0.10.0 bump | `uv lock --check` |
|---|---|---|
| static (before) | lock now stale | fails |
| dynamic (after) | lock unchanged — no version recorded | passes |

release-please now updates `src/__about__.py` through its **generic**
(comment-annotation) updater instead.

## Also dropped

The `uv.lock` entry added to `release-please-config.json` in #72 was a
silent no-op. Its jsonpath is evaluated by `jsonpath-plus`, which does
not apply the `[?(@.name=='labops')]` filter, so it matched nothing and
only logged a warning — visible in the Release Please run for #70:

```
⚠ No entries modified in $.package[?(@.name=='labops')].version
```

Non-matching paths only warn, never fail, which is why #72 looked like
it worked.

## Verification

- `uv lock` → `Updated labops v0.9.1 -> (dynamic)`; the `version` field
is gone from the lock
- `uv sync --locked` passes from a clean environment and installs
`labops==0.9.1`
- bumping `__about__.py` to `0.10.0` leaves `uv lock --check` passing,
and `uv build` produces `labops-0.10.0` artifacts
- 550 tests pass; `ruff check` clean

Not verifiable locally: that release-please actually rewrites the
annotated line — that only proves out on the next Release Please run. It
uses the annotation-based generic updater rather than the jsonpath path
that failed before.

## After merge

release-please regenerates #70 against the new config, bumping
`src/__about__.py` instead of `pyproject.toml`, and its stale-lock diff
disappears.
FreezeManny added a commit that referenced this pull request Aug 19, 2026
🤖 I have created a release *beep* *boop*
---


##
[0.10.0](labops-v0.9.1...labops-v0.10.0)
(2026-08-19)


### Features

* short web service
([#69](#69))
([a526369](a526369))


### Bug Fixes

* build pipeline
([#72](#72))
([c8b9de6](c8b9de6))
* derive the version from src/__about__.py
([#74](#74))
([d5b8511](d5b8511))

---
This PR was generated with [Release
Please](https://github.com/googleapis/release-please). See
[documentation](https://github.com/googleapis/release-please#release-please).
@FreezeManny
FreezeManny deleted the 71-fix-build-pipeline branch August 19, 2026 15:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

fix build pipeline

1 participant