Expose every release a build has been put into - #1255
Merged
Conversation
builds.release_id only keeps the release a build got into last, so a
build released more than once, to different products or platforms, has
no way to tell about the earlier releases. The build to releases link
lives on the other side, in build_releases.build_ids, and there is no
way to query it: GET /releases/ takes no build_id, and every release it
returns carries the whole release plan, megabytes of it.
Add GET /builds/{build_id}/releases/, which looks the history up from
the releases side with :build_id = ANY(build_ids). Columns are selected
explicitly so the plan stays out of both the query and the response.
Reverted releases are returned along with the rest, each with its
status, and it is up to the caller to decide what to show.
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.
Summary
builds.release_idonly keeps the release a build got into last —commit_release()overwrites it for every build in the plan — so a build released more than once has no way of telling about its earlier releases. Build 77924 is released both toalmalinux10-beta(51142) and to AlmaLinux Kitten 10 (50862), and the API reports only the former.The build-to-releases link lives on the other side, in
build_releases.build_ids, and nothing exposes it:GET /releases/takes nobuild_id, and every release it returns carries the whole release plan — release 51142 alone serializes to 2.3 MB — so walking the release feed is not an option for a caller either.Changes
GET /builds/{build_id}/releases/on the public router, since the build page is public. Returnsid,status,created_at,platform_nameandproduct_nameper release, newest first.build_crud.get_build_releases()looks the history up from the releases side with:build_id = ANY(build_releases.build_ids), joins platform and product, and selects columns explicitly soplanstays out of both the query and the response. Answers are hundreds of bytes.build_schema.BuildReleasefor the returned rows.Testing
tests/test_api/test_releases.py::test_get_build_releases, placed before the revert tests so the release it looks up is stillCOMPLETED.py_compileclean and the array containment compiles to the expected:id = ANY (build_releases.build_ids).build_releasesholds ~8.4k rows, so the sequential scan behind= ANY(...)is cheap. A GIN index onbuild_idscan be added later if the table grows.Frontend counterpart: AlmaLinux/albs-frontend#605