The GitHub Actions job "Required Checks" on texera.git/gh-readonly-queue/main/pr-8518-08c1ee9c44fa40c35d931552a6ea078c20819fbf has succeeded. Run started by GitHub user aicam (triggered by aicam).
Head commit for run: 5865f2af0b88129144b25eeddef53842a885fed5 / Tanishq Gandhi <[email protected]> feat(frontend): manage curated computing-unit images from the admin page (#8518) ### What changes were proposed in this PR? **Admin → CU Images**, the page for managing the images #8475 made registrable. Images are listed newest first, each with the digest a unit will actually run, and four actions: Add, Log, Refresh, Remove. A row shows PENDING, VALIDATING, READY or FAILED. The list polls while a check is running and goes quiet once nothing is.  **Log is the point of the page.** It is where a refused image explains itself — a tag that does not exist, an image that is not a computing-unit image — and says what to do instead.  A deployment with curated images switched off is told so plainly. The API answers 503 on every endpoint there, so the page can do nothing either way; saying that beats an error an administrator cannot tell from a broken deployment.  Also routes `/api/cu-image` to the computing-unit manager in the dev proxy. Without it a local frontend reaches the webserver instead and every call 404s. Production already routes through the gateway, added in #8475. ### Any related issues, documentation, discussions? Closes #8470 Part of #8466 Stacked on #8475, whose API this consumes, so GitHub shows that commit here too until it merges. This PR's own change is one commit over it, frontend only. ### How was this PR tested? Nine tests for the page, plus the whole thing run against a real backend. | Case | What it pins | | --- | --- | | digest shown | the pinned digest reaches the page, not just the tag | | feature off | 503 becomes an explanation, not an error | | no poll when off | an idle switched-off page makes no requests | | polls, then stops | requests while a check runs, none once it settles | | newest first | ordered by time, not by name | | blank fields | no request is made | | Refresh while checking | disabled | | status colours | READY, FAILED and in-progress are distinguishable | ``` yarn --cwd frontend format:ci clean yarn --cwd frontend run build:ci 0 errors yarn --cwd frontend run test:ci 29 passed (9 new, plus dashboard.component.spec) ``` The polling tests were mutation-checked: removing the filter fails exactly those two. **Against a real stack** (`bin/local-dev.sh up`, with the computing-unit manager talking to minikube): ``` register alpine:3.20 -> FAILED in 8s, digest sha256:d9e853e8... log: "Its start command is: [/bin/sh]" register texera-cu-sklearn:1.0 -> READY in 15s, digest sha256:7e0a8816... matches skopeo inspect independently refresh -> attempt 1 -> 2, back to READY remove -> 204 duplicate reference / name / blank name -> 400, each naming the reason a Docker Hub page address -> normalised to owner/name:latest REGULAR user: GET 200, POST/DELETE/log -> 403 ``` Driven through the page itself: typed into the Add form, clicked Add, the row appeared VALIDATING and reached its outcome with no further interaction. Once settled, 0 requests over 20 idle seconds. The screenshots above are that stack, not a mock. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (Claude Opus 5) --------- Co-authored-by: ali risheh <[email protected]> Report URL: https://github.com/apache/texera/actions/runs/35179327146 With regards, GitHub Actions via GitBox
