Skip to content

fix(frontend, v1.2): render workflow covers on the hub landing page - #8390

Draft
github-actions[bot] wants to merge 1 commit into
release/v1.2from
backport/8383-render-workflow-covers-on-the-hub-landin-v1.2
Draft

fix(frontend, v1.2): render workflow covers on the hub landing page#8390
github-actions[bot] wants to merge 1 commit into
release/v1.2from
backport/8383-render-workflow-covers-on-the-hub-landin-v1.2

Conversation

@github-actions

@github-actions github-actions Bot commented Sep 3, 2026

Copy link
Copy Markdown
Contributor

What changes were proposed in this PR?

Automated backport of #8383 to release/v1.2.

Source: 1facefb · automation run

Any related issues, documentation, discussions?

Backport of #8383. Originally linked #8382.

How was this PR tested?

Release-branch CI runs on this branch once the conflicts are resolved and this PR is marked ready for review.

Was this PR authored or co-authored using generative AI tooling?

No.

### 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 1facefb)

Generated-by: Claude Code (Opus 5)
@github-actions

github-actions Bot commented Sep 3, 2026

Copy link
Copy Markdown
Contributor Author

The cherry-pick conflicted and was committed with conflict markers. Resolve the conflicts on this branch, then mark this PR ready for review.

Conflicting files:

  • frontend/proxy.config.json
  • frontend/src/app/hub/component/browse-section/browse-section.component.spec.ts
  • frontend/src/app/hub/component/browse-section/browse-section.component.ts

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant