The GitHub Actions job "Release Auditing" on texera.git/backport/8383-render-workflow-covers-on-the-hub-landin-v1.3 has failed. Run started by GitHub user github-actions[bot] (triggered by github-actions[bot]).
Head commit for run: bfbf2c552ebbce6611500070766feddb0fce8297 / Tanishq Gandhi <[email protected]> fix(frontend): render workflow covers on the hub landing page (#8383) ### What changes were proposed in this PR? Workflow covers never rendered on the Hub landing page: every card under **Top Loved Workflows** and **Top Cloned Workflows** showed the grey placeholder, even for a workflow whose owner had set a cover, while the same workflow showed it correctly in Your Work → Workflows. Covers reach the frontend two different ways. A **workflow** cover is a downscaled **data URL** that arrives inline on the list payload and lands on `DashboardEntry.coverImageUrl`. A **dataset** or **model** cover is a committed file, so what arrives is a *path* and the card has to fetch a presigned URL from `/{id}/cover-url`. `browse-section` only ever handled the second kind — it asks the descriptor for a `coverUrl` and bails when there is none, which is always the case for a workflow, since `WorkflowResourceDescriptor` deliberately declares none. So nothing was ever cached for a workflow and `getCoverImage` fell through to the default. `getCoverImage` now reads a workflow's cover straight off the entry, mirroring the branch `card-item.component.ts:197-202` already had. Also included, since it is one line in the same area and needs no separate issue: `frontend/proxy.config.json` declared `"/api/model/**"` **twice** (both pointing at `:9092`, so the last silently won). The duplicate is removed, leaving the entry beside `/api/dataset`, so the file reads `dataset`, `model`, `access/dataset`, `access/model`. **Before** — both workflows are public; the left one has a cover, the right one does not: <img width="1440" height="900" alt="issue5-1-hub-landing-before" src="https://github.com/user-attachments/assets/120c2cf3-2ee9-49e0-97df-a77e3746275c"; /> **After** — the left card renders its cover, the right one still shows the placeholder: <img width="1440" height="900" alt="issue5-1-hub-landing-after" src="https://github.com/user-attachments/assets/9c0294a0-f081-4428-a230-80281a40cb7a"; /> ### Any related issues, documentation, discussions? Closes #8382. ### How was this PR tested? `browse-section.component.spec.ts`, 25 passed: - `renders a workflow's cover from the entry, since no cover is ever fetched for one` — a workflow with a cover resolves to it, one without still gets the default. - `keeps a file-backed kind on the placeholder rather than rendering its stored cover path` — a dataset whose presigned fetch answers with an empty URL stays on the placeholder instead of rendering `v1/images/preview.png`. - `skips an entity whose descriptor resolves no cover, rather than calling undefined` was already there and asserted `getCoverImage(workflow) === defaultBackground` — it pinned the bug, so it now asserts the cover comes off the entry, with the unregistered-kind row still falling back. `landing-page.component.spec.ts` also run, 17 passed. ``` cd frontend npx ng test --include src/app/hub/component/browse-section/browse-section.component.spec.ts npx ng test --include src/app/hub/component/landing-page/landing-page.component.spec.ts ``` Checked by hand against a local stack: a public workflow with a cover set from the dashboard now shows it in both hub sections, and a public workflow without one is unchanged. ### Was this PR authored or co-authored using generative AI tooling? (backported from commit 1facefb183c96e7b426ff6be35e5b6aaa7b33345) Generated-by: Claude Code (Opus 5) Report URL: https://github.com/apache/texera/actions/runs/33813227114 With regards, GitHub Actions via GitBox
