Link every release of a build and select release projects in bulk - #605
Open
eabdullin1 wants to merge 2 commits into
Open
Link every release of a build and select release projects in bulk#605eabdullin1 wants to merge 2 commits into
eabdullin1 wants to merge 2 commits into
Conversation
Assembling a release out of a large build meant clicking every project one by one. Add "Select all" and "Unselect all" next to the search field. "Select all" leaves out the projects with failed build tasks, the very ones the form unselects by default, so those still have to be picked by hand. Both the form and the release update page now keep track of which projects those are.
builds.release_id only keeps the release the build got into last, so a
build released twice, say to a beta product and to Kitten, showed a
single "Released" chip with no way to reach the other release. List
every release of the build next to that chip, each one a link carrying
its own status, and leave the reverted ones out.
The list comes from the new GET /builds/{build_id}/releases/ endpoint.
Until it is deployed the page falls back to builds.release_id, which
keeps today's behaviour and links the last release alone.
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
1 participant
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.
Two independent changes, one to the build page and one to the release form.
Every release of a build on the build page
builds.release_idonly keeps the release a build got into last, so the build page showed a single "Released" chip whose cloud linked to that one release, and everything before it was unreachable: build 77924 is released toalmalinux10-beta(51142) and to Kitten 10 (50862), and only 51142 could be reached.The "Released" chip stays exactly as it was, driven by
builds.released. Next to it the page now lists every release of the build, each one a link carrying its own status in the same dense coloured chip the release feed and the release page already use. Reverted releases are left out.The list comes from
GET /builds/{build_id}/releases/, added in AlmaLinux/albs-web-server#NNN. Until that is deployed the page falls back tobuilds.release_id, which keeps today's behaviour and links the last release alone, so this can be merged independently of the backend.A side effect worth naming: a build sitting in a release plan that has not been committed yet —
releasedstill false,release_idstill null — was invisible on the page and now shows up as a grey "Scheduled" chip.Select all / Unselect all in the build selection form
Assembling a release out of a large build meant ticking every project by hand. The form gets "Select all" and "Unselect all" next to the search field. "Select all" leaves out the projects with failed build tasks — the very ones the form unselects by default — so those still have to be picked deliberately. Both the selection form and the release update page now keep track of which projects those are.
Verification
Checked against production data: a local build of the SPA with every
/api/v1request proxied to build.almalinux.org and only the new endpoint answered locally. Build 77924 renders both releases as links, clicking one opens the release page,Completed/Scheduled/Failedcome out in their own colours, reverted releases do not render, and with the endpoint answering 404 the page falls back to the single last release as before.