develop -> main - #924
Merged
Merged
Conversation
With capture disabled, the flip-utils suite crashes at interpreter exit in CI (OSError: [Errno 9] Bad file descriptor on sys.stdout.flush, exit code 120) after every test has passed, killing the release job before publish. Run pytest with default capture; verified locally: 653 passed. Signed-off-by: at24_bioeng625-pc <alexandre.triay_bagur@kcl.ac.uk>
Root and changed services go to 0.4.0 (flip-api, flip-ui, imaging-api, data-access-api); trust-api to 0.3.1 (dependency updates only since v0.3.0). flip-utils goes to 0.4.1 rather than staying at 0.4.0: that version was never published (release-pypi has failed on every run since June) and its v0.4.0 tag would collide with the platform release tag that release.yml creates on the same push to main. Signed-off-by: at24_bioeng625-pc <alexandre.triay_bagur@kcl.ac.uk>
trust-api was held at 0.3.1 in the v0.4.0 release because only its dependencies changed since v0.3.0. Track the platform version instead so every FLIP component reports the same version as the release tag, which makes image tags, deployed services and support requests line up without a per-service lookup. Signed-off-by: Claude <noreply@anthropic.com>
Release v0.4.0
📋 Release Notes Preview — flip v0.4.1📦 FLIP 0.4.1 Release Notes✨ Highlights
|
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Closed
4 tasks
atriaybagur
added a commit
that referenced
this pull request
Aug 7, 2026
The release-notes preview read flip-utils/flip/__init__.py, but flip-utils ships to PyPI as `flip` and is versioned independently of the platform, so the preview described a different artefact than the one being released. Read the root pyproject.toml instead, exactly as release.yml does when it mints the tag. The two most recent release PRs both announced the wrong number: #924 said v0.4.1 for a v0.4.0 cut, #808 said v0.4.0 for v0.3.0. The changelog section never rendered either. generate-notes requires contents:write and the workflow granted contents:read, so every call failed with "Resource not accessible by integration" and the comment fell back to bare template text. Override to contents:write at the job level, matching release.yml, and keep the workflow default read-only. That fallback is why this survived two releases unnoticed: it read as an empty release rather than a broken workflow. Report the API error through core.warning and in the comment body so the next failure is legible. Signed-off-by: at24_bioeng625-pc <alexandre.triay_bagur@kcl.ac.uk>
20 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Cuts the v0.4.0 release: promotes
developintomainper CONTRIBUTING"Cutting a release".
This is a deliberately small diff — 14 files, +15/-15. The feature work for this release was already
promoted by #808 (merged 2026-08-06); everything here is the version bump (#917) plus one release-pipeline
fix bundled with it. Nothing else has landed on
developsince.Commits:
20a4072f,0f57d781,181dd447, merged viafcd964c5(#917).Version bumps
v0.4.0release tag)flipon PyPI)trust-api tracks the platform version. Only its dependencies changed since v0.3.0, so a strict semver
read would make it 0.3.1 — but holding one service back means image tags, deployed services and support
requests no longer line up without a per-service lookup. It moves to 0.4.0 with everything else.
flip-utils is the deliberate exception and goes to 0.4.1, not 0.4.0. It is published to PyPI as
flipand has its own consumers, so its version stays independent.
release.yml(reads the root version) andrelease-pypi.yml(readsflip.__version__) mint tags into the samev*namespace and both fire on everypush to
main. flip 0.4.0 was never published or tagged (release-pypi has failed on every run since June),so once this merges
release.ymlwould claimv0.4.0and release-pypi's tag-exists check would then skippublishing flip 0.4.0 permanently. 0.4.1 sidesteps the collision for this release; separating the tag
namespaces (e.g. a
flip-utils-v*prefix) is the proper long-term fix.Release-pipeline fix bundled in
Drop
-sfrom the release-pypi pytest invocation (20a4072f). The run onmainafter #808 mergedcrashed at interpreter exit with
OSError: [Errno 9] Bad file descriptoronsys.stdout.flush(exit code120) after every test had passed, killing the release job before publish. With default capture the suite is
clean — verified locally on uv-synced deps: 653 passed.
What merging this triggers
release.yml— reads the rootpyproject.tomlversion, creates thev0.4.0tag and a GitHub Release withauto-generated notes.
docker_build_*.yml— rebuilds every service and pushes the:prodimage tag (alongside:<sha>) to GHCR.release-pypi.yml— attempts to publishflip0.4.1 to PyPI.The June release-pypi run got past tests and failed at publish with
422 invalid-publisher: PyPI trustedpublishing for the
flipproject does not match this repo/workflow/environment (workflowrelease-pypi.yml,environment
flip). Until that is configured on pypi.org the PyPI leg will keep failing. The platform release(
release.ymltag + GitHub Release +:prodimages) is independent and unaffected.Linked Issues
None — this is a release cut. Issue links live on the individual PRs promoted by #808 and on #917.
Checklist
Type of Change
make -C docs/ docs.Testing
Verification carried out on #917 before it merged to
develop:uv lock --checkpasses on all five re-locked projects (uv 0.11.16 — CI's pinned version).ruff checkclean;pytest -vvwithout-s: 653 passed.no path filtering).
Additional Notes
developshows as 3 commits behindmain— those are themain-only merge commits from PRs #531, #654 and#808. That is the normal shape of this repo's release flow (
mainis never merged back intodevelop) anddoes not conflict; GitHub reports the PR as mergeable.
Ignore the version in the release-notes preview comment below — it says
v0.4.1, which is wrong.pr-release-notes-preview.ymlreadsflip-utils/flip/__init__.py(the PyPI package version) instead of theroot
pyproject.tomlthatrelease.ymlactually tags from, so it is previewing flip-utils, not the platformrelease. The release this PR cuts is
v0.4.0. The same comment's empty changelog is a second, separatefault: the workflow grants itself
contents: read, butreleases/generate-notesneedscontents: write, sothe API call fails with
Resource not accessible by integrationand the template renders unpopulated. Bothfaults pre-date this PR — the preview on #808 likewise announced
0.4.0for what was cut asv0.3.0.