Repository navigation
Conversation
erni-a
left a comment
erni-a
left a comment
There was a problem hiding this comment.
Thanks @miyannishar, the extra-files entries are exactly the shape #1213 used and RELEASING.md now lists the service. One number to change before merge: main has moved to 3.19.2 since you branched (core-api/pyproject.toml is the reference), so please set core-operations/pyproject.toml and its uv.lock entry to 3.19.2 rather than 3.19.0, so all four services carry the same version when release-please next bumps them. Push that and I will approve the CI run and merge the same day.
|
Thanks! Bumped core-operations to 3.19.2 and merged main in, which also picks up #1719 so the mypy failure on core-storage-api should be gone now. All eight version files match the manifest. |
|
@erni-a main shipped 3.20.1 since my last push, so I bumped core-operations to 3.20.1 and merged main again. CI was green on the previous commit. If you get a chance to merge before the next release that'd be great, otherwise it'll drift again. Thanks! |
#1983) Fixes part 1 of **M-01** from the 2026-10-01 OSS audit. ## Every service lock is checked Each service image installs its own `uv.lock` as it stands (`uv export --frozen`), while CI tests the pyproject ranges, resolved afresh, and nothing checked that a lock still matched its pyproject. A pyproject edit made without a re-lock passed CI and was missing from the image. - **The check:** the CI job now runs `uv lock --check --directory <service>` for all four services, before it installs anything, and names every stale lock in one error. `uv lock --check` fails when re-locking would change the lock; it exists since uv 0.5.8, and CI runs 0.9.26. - **Main passes it today**, as far as reading the files can tell: in all four locks, the requirements, extras, dependency groups, Python range and version they recorded match their pyprojects, before and after release #1980. - **Bots keep the locks in step:** release-please bumps each service's version in its `uv.lock` with its `pyproject.toml` (#1717 does the same for core-operations), Dependabot's uv updates re-lock, and its pip updates touch only the root `requirements.txt`. ## core-worker's image is built No workflow built core-worker's image, the write path in deferred mode. The image job ("core-api image bakes a real version") now builds it and runs `python -c "import uvicorn, core_worker.app"` inside it: the app its CMD serves, from what the image installed. In CI's shared venv another service's dependency can stand in for one core-worker never declared; in the image it cannot. The import needs no environment: every setting has a default, `ddtrace` is imported under `try/except ImportError`, and the event bus and storage client start only in the app's lifespan. Every other third-party module the app loads at import is a declared core-worker dependency. ## Tests `tests/test_m01_every_lock_is_checked_and_every_image_built.py` fails when a service's `uv.lock` is not named in a ci.yml step that runs `uv lock --check`, or a service's Dockerfile is not built by a ci.yml `docker build`. A guard checks that the scans find all four services, and the core-api image build. | Push | Run | Result | |---|---|---| | Tests alone (46383fe) | [37622734288](https://github.com/caura-ai/caura/actions/runs/37622734288) | Failed exactly the 2 new cases: no ci.yml step checked any of the four locks, and no `docker build` built core-worker's Dockerfile. The guard and 9,654 other tests passed. The first push (46383fe) had stopped at the root-tests ruff check (SIM300) before the tests ran; the amend flipped two comparisons. | | Fix added (1e9036f) | [37624349643](https://github.com/caura-ai/caura/actions/runs/37624349643) | This PR's checks | ## Not in this PR - **Part 2 of M-01**, CI installing from the service locks, waits on aligning SQLAlchemy: core-api's lock pins 2.0.50 and core-storage-api's 2.1.0. - **L-01**, making the image job a required check, is a branch-protection setting. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Signed-off-by: eldad-caura <eldad@caura.ai> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
release-please-config.json listed the pyproject.toml and uv.lock of core-api, core-worker and core-storage-api as extra-files, but not core-operations, so its version stayed at 1.0.0 while the backend release moved on to 3.19.0. Add core-operations/pyproject.toml and its editable uv.lock entry, using the same shape caura-ai#1213 introduced for the other services, bring both to the current release version, and list them in RELEASING.md. Closes caura-ai#716. Signed-off-by: Nishar <nishar@dayos.com>
8e75bb1 to
6dc39ff
Compare
|
@miyannishar I rebased your branch onto current main (one commit, still authored and signed by you) so it could merge: core-operations synced to 3.30.6, which is where main is today, and RELEASING.md resolved against #1987's rewrite of that section. tests/test_l90_release_docs_match_release_please.py passes, so the doc and the release-please config agree. On the release-PR interplay you flagged: release-please will simply bump core-operations with the other three from here on, which is the point of the change. Merging once CI is green. Thanks for the patience on this one. |
erni-a
left a comment
erni-a
left a comment
There was a problem hiding this comment.
Re-approving after the rebase. Same change as approved on Sept 27 and Oct 2, now one commit on current main with the version synced to 3.30.6 and the release-docs parity test passing.
🤖 I have created a release *beep* *boop* --- <details><summary>backend: 3.30.7</summary> ## [3.30.7](backend-v3.30.6...backend-v3.30.7) (2026-10-11) ### Bug Fixes * a bulk item's null weight gets the column default (L-97) ([#2036](#2036)) ([25bc89e](25bc89e)) * **client-python:** raise CauraAPIError for non-JSON 2xx bodies ([#2013](#2013)) ([d6580f7](d6580f7)) * **client-typescript:** raise CauraApiError for a non-JSON 2xx body ([#2014](#2014)) ([9ba140d](9ba140d)) * **clients:** parse HTTP-date Retry-After values ([#2010](#2010)) ([f575803](f575803)) * **events:** type pull_executor concretely in _hold_leases ([#1596](#1596)) ([#1698](#1698)) ([45dff80](45dff80)) * **release:** keep the core-operations version in sync ([#1717](#1717)) ([96a7907](96a7907)) * storage answers for the database it has (B28) ([#2033](#2033)) ([67a0a57](67a0a57)) </details> --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Signed-off-by: release-please[bot] <release-please[bot]@users.noreply.github.com> Co-authored-by: caura-deploy-bot[bot] <265395343+caura-deploy-bot[bot]@users.noreply.github.com>
2 participants
Summary
Add
core-operations(pyproject + uv.lock) to release-pleaseextra-files, as #1213 did for the other services, and sync it to3.20.1.Related Issue
Closes #716
Type of Change
How Has This Been Tested?
core-operations: ruff, mypy,uv lock --check,pytest(90 passed). All eight backend version files resolve to3.20.1.Checklist
ruff checkandruff format --checkpassmypypassespytestpasses locally:core-operationssuite onlyRELEASING.mdCHANGELOG.mdunder theUnreleasedsection (if user-facing): N/A, generated by release-pleaseAdditional Notes
N/A