Fix newsletter proposal HTML: duplicate pipelines and wrong accepted status by ewels · Pull Request #4342 · nf-core/website

ewels · 2026-08-01T19:35:07Z

Done on my phone in a campsite, so please forgive the AI blurb description. 'cc @jfy133 who reported.

Two bugs in the newsletter "New pipelines & proposals" section:

A pipeline proposal was marked "accepted" whenever its issue was closed
on GitHub with state_reason "completed". But nf-core/proposals closes
rejected/withdrawn proposals as "completed" too, so e.g. dragen (New: website search functionality #137,
labelled "proposed") showed up as accepted. Acceptance is actually
tracked with the "accepted" label, so key on that instead. A proposal
closed without the label and not opened that month now drops out
entirely, as intended.
When a pipeline proposal is accepted, its repo is created the same
month and already appears under "New pipeline repositories", so the
pipeline was listed twice (e.g. pathogenepidemiology). Drop the
proposal entry when a matching new repo is present for that month.

Update the getProposalsForMonth unit test to cover label-based
acceptance and the completed-but-not-accepted case.

Co-Authored-By: Claude Opus 4.8 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_01X2KaU4537UFKLW6Kw1rSSt

@netlify /blog/2026/tools-4_1_0

…status Two bugs in the newsletter "New pipelines & proposals" section: - A pipeline proposal was marked "accepted" whenever its issue was closed on GitHub with state_reason "completed". But nf-core/proposals closes rejected/withdrawn proposals as "completed" too, so e.g. dragen (#137, labelled "proposed") showed up as accepted. Acceptance is actually tracked with the "accepted" label, so key on that instead. A proposal closed without the label and not opened that month now drops out entirely, as intended. - When a pipeline proposal is accepted, its repo is created the same month and already appears under "New pipeline repositories", so the pipeline was listed twice (e.g. pathogenepidemiology). Drop the proposal entry when a matching new repo is present for that month. Update the getProposalsForMonth unit test to cover label-based acceptance and the completed-but-not-accepted case. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01X2KaU4537UFKLW6Kw1rSSt

netlify · 2026-08-01T19:35:11Z

✅ Deploy Preview for nf-core-main-site ready!

Name	Link
🔨 Latest commit	`e45dc92`
🔍 Latest deploy log	https://app.netlify.com/projects/nf-core-main-site/deploys/6a856bdd838b91000865a98d
😎 Deploy Preview	https://deploy-preview-4342--nf-core-main-site.netlify.app/blog/2026/tools-4_1_0
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

ewels · 2026-08-01T19:36:56Z

@nf-core-bot fix linting

Playwright 1.62's config loader resolves the `extends` of sites/main-site/tsconfig.json but cannot follow the bare package specifier "astro/tsconfigs/base" when astro is hoisted to the workspace root node_modules. This made `playwright test` fail at config-load time with "Failed to resolve extends path", so no tests ran at all. Point `extends` at the hoisted location via a relative path so the config loads. astro/editors/tsc all resolve relative extends natively, and npm workspaces always hoist astro to the repo-root node_modules. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01X2KaU4537UFKLW6Kw1rSSt

ewels · 2026-08-13T12:26:41Z

@@ -1,5 +1,5 @@
 {
-    "extends": "astro/tsconfigs/base",
+    "extends": "../../node_modules/astro/tsconfigs/base.json",


@mashehu this looks a bit dodgy to me? Wanted to flag it. Otherwise the rest of the PR is fairly uncontroversial I think.

🤖 explanation:

The Playwright CI job was failing before this — not on a test, but at config-load time:

Failed to resolve "extends" path "astro/tsconfigs/base" referenced from sites/main-site/tsconfig.json

So playwright test died before running a single test. Cause: Playwright 1.62's tsconfig loader resolves extends through the package's exports map, and astro's package.json doesn't expose the ./tsconfigs/base subpath. tsc, astro and the editor use classic/their-own resolution and find the file fine, which is why only Playwright trips over it. It's made worse by npm workspaces hoisting astro up to the repo-root node_modules, so it isn't in sites/main-site/node_modules for a naive lookup either.

Pointing extends straight at the hoisted file sidesteps the exports map and resolves for every tool. It's ugly but deterministic (workspaces always hoist astro to root).

Cleaner alternatives if we'd rather not hardcode the path:

Bump Playwright to a version whose loader resolves the bare package extends again — smallest conceptual change, but a dependency bump to validate across the suite.

Give Playwright its own tsconfig: leave tsconfig.json extending astro/tsconfigs/base for astro/editors, and point Playwright at a tiny dedicated tsconfig that just carries the @utils/* etc. path aliases (no astro extends). Keeps the shared file untouched; adds one small config file.

Skip the extends for Playwright entirely — the config only needs the path aliases, not astro's compiler options.

I am not too sure about the relative path. Will need to double check that it doesn't break other builds.

Yup you're right, I think they'd be borked. Reverted and did option (2) instead in 771681b

Ok should be good now I think @mashehu ?

Revert sites/main-site/tsconfig.json back to `extends: astro/tsconfigs/base` so it is identical to every other subsite again and no Netlify site build sees a changed config. The previous relative-path hack lived in the shared file, which risked the other per-subsite builds. Confine the workaround to Playwright: add a self-contained tsconfig.playwright.json (just the path aliases, no astro extends) and run `playwright test --tsconfig=tsconfig.playwright.json`. Playwright 1.62 uses that single tsconfig for config + tests, so it never tries to resolve the `astro/tsconfigs/base` package specifier that its loader chokes on, while astro/editors keep using the untouched shared tsconfig. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01X2KaU4537UFKLW6Kw1rSSt

The same Playwright 1.62 failure that hit main-site applies to every subsite: each tsconfig.json extends `astro/tsconfigs/base`, which Playwright's config loader can't resolve when astro is hoisted to the workspace root, so `playwright test` aborts before running any test (verified: docs/configs/modules-subworkflows/pipeline-results/pipelines all fail to load otherwise). Mirror the main-site fix for each: add a self-contained tsconfig.playwright.json (that site's own path aliases, no astro extends) and pass `--tsconfig=tsconfig.playwright.json` on the test script. The shared tsconfig.json files are left untouched, so astro/editors and the per-subsite Netlify builds are unaffected. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01X2KaU4537UFKLW6Kw1rSSt

Only main-site's tests import a path alias (@utils, which transitively pulls in @components etc.); every other subsite's tests import just @playwright/test. So a single self-contained tsconfig at sites/ — with main-site's alias set resolved relative to that dir — covers all sites. Replace the six per-site tsconfig.playwright.json files with one shared sites/tsconfig.playwright.json and point each test script at `--tsconfig=../tsconfig.playwright.json`. Shared tsconfig.json files stay untouched. Verified: main-site's 21 unit tests pass and every subsite's config loads through the shared file. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01X2KaU4537UFKLW6Kw1rSSt

mashehu · 2026-08-14T09:47:33Z

why does playwright need compilerOptions with path aliases? that feels wrong? if it just needs to have some dummy tsconfig I would just make an empty one.

The test file sites/main-site/tests/newsletter.spec.ts does import { … } from "@utils/newsletter", and without the paths entries in tsconfig, Playwright's TS resolution will fail with a module-not-found error before any test runs.

ok if I use relative paths in the newsletter test file then it can be empty. I thought that going back to relative paths like this would break stuff but Claude assures me that it should be fine. Will push now.

Done in 6edd141

Nope, it broke everything as I suspected. Reverting..

ewels · 2026-08-19T09:42:25Z

Now hanging during playwright browser install for some reason 🙈

github-actions Bot deleted a comment from netlify Bot Aug 1, 2026

nf-core-bot and others added 3 commits August 1, 2026 19:38

[automated] Fix code linting

51b5b58

Merge branch 'main' into claude/newsletter-proposal-html-bugs-ut4y6m

1f80e5c

ewels requested a review from mashehu August 13, 2026 12:25

ewels commented Aug 13, 2026

View reviewed changes

jfy133 approved these changes Aug 14, 2026

View reviewed changes

claude and others added 4 commits August 14, 2026 07:13

Merge branch 'main' into claude/newsletter-proposal-html-bugs-ut4y6m

d06c210

mashehu reviewed Aug 14, 2026

View reviewed changes

vagkaratzas mentioned this pull request Aug 18, 2026

add agentic modules hackathon project #4353

Merged

ewels added 4 commits August 18, 2026 12:01

Merge branch 'main' into claude/newsletter-proposal-html-bugs-ut4y6m

24d46ae

Simplify playwright tscondig to be empty placeholder

6edd141

Fix relative path

843ea47

Revert aliases

e45dc92

Navigation Menu

Uh oh!

Fix newsletter proposal HTML: duplicate pipelines and wrong accepted status - #4342

Fix newsletter proposal HTML: duplicate pipelines and wrong accepted status#4342
ewels wants to merge 12 commits into
mainfrom
claude/newsletter-proposal-html-bugs-ut4y6m

ewels commented Aug 1, 2026 •

edited by nf-core-bot

Loading

Uh oh!

netlify Bot commented Aug 1, 2026 •

edited

Loading

Uh oh!

ewels commented Aug 1, 2026

Uh oh!

ewels Aug 13, 2026

Uh oh!

ewels Aug 13, 2026

Uh oh!

mashehu Aug 14, 2026

Uh oh!

ewels Aug 14, 2026

Uh oh!

ewels Aug 14, 2026

Uh oh!

mashehu Aug 14, 2026

Uh oh!

ewels Aug 19, 2026

Uh oh!

ewels Aug 19, 2026

Uh oh!

ewels Aug 19, 2026

Uh oh!

ewels Aug 19, 2026

Uh oh!

ewels commented Aug 19, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Conversation

ewels commented Aug 1, 2026 • edited by nf-core-bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

netlify Bot commented Aug 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Deploy Preview for nf-core-main-site ready!

Uh oh!

ewels commented Aug 1, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ewels commented Aug 19, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

ewels commented Aug 1, 2026 •

edited by nf-core-bot

Loading

netlify Bot commented Aug 1, 2026 •

edited

Loading