Remove upvote counter from landing-page cards - #495
Merged
soyalejolopez merged 1 commit intoJul 22, 2026
Merged
Conversation
The card upvote count was baked into a static resource-stats.json that is only regenerated by a daily CI job (cron 0 6 * * *), so a fresh reaction would not show up for up to ~24h. Combined with the fact that only one resource currently has a backing discussion, the counter was misleading. This removes the upvote count *display* from both the comfortable and compact card views (and the compact 'Votes' header column + orphaned CSS). Voting itself is unchanged: the giscus-backed 'Community & upvotes' panel on the detail page still works, and the upvotes value is still loaded in getStats and used by the Popular/Trending/Engaging sort logic. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 888b1353-6309-4a90-bb0f-9b7b716a32dc
soyalejolopez
added a commit
that referenced
this pull request
Jul 27, 2026
…per (#502) * Surface the real error when traffic collection fails The Collect Traffic Data workflow has failed every day since 7/6 with no usable diagnostic. Two bugs conspired to hide the cause: - gh_api_retry sent gh's stderr to /dev/null, so the retry warnings said "attempt N/3 failed" and nothing else. - fetch_required_json echoed its ::error:: to stdout while running inside a command substitution, so the error text was captured into the caller's variable instead of reaching the log. Now the real gh stderr is preserved and included in the retry warning, errors route to stderr and return instead of exiting from a subshell, and an empty TRAFFIC_TOKEN fails immediately with a message naming the secret and the administration:read scope it needs. Also skips the pointless sleep after the final attempt. The underlying failure is an expired TRAFFIC_TOKEN. This does not fix that, but it makes the next failure legible in one glance. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 68fa07a3-7ce8-442f-a9e8-f6b1775d8a1f * Stop the message center refresh dying on the Actions PR policy Every weekly run since 7/20 has pushed its branch successfully and then failed on gh pr create with: GitHub Actions is not permitted to create or approve pull requests That is a repo setting, not a bug in the run, and it should not throw away a branch that already landed. The step now recognises that specific error, emits a warning plus a job summary with a compare URL, and exits 0. Any other create failure still fails the job. Two supporting fixes: - --force-with-lease was failing with "stale info" because actions/checkout only fetches the default branch, so refs/remotes/origin/<branch> never existed on a same-day rerun. The ref is now seeded before the push. - GH_TOKEN falls back to AUTOMATION_PAT when present, which sidesteps the policy entirely for repos that add one. Also adds set -euo pipefail and drops an || true that was masking gh pr list failures. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 68fa07a3-7ce8-442f-a9e8-f6b1775d8a1f * Route catalog rebuilds through a PR when master is protected Half the recent Build catalog runs failed with: remote: error: GH006: Protected branch update failed for refs/heads/master - Changes must be made through a pull request. The publish job pushes catalog.json, resource-stats.json, resource-discussions.json and traffic-data/clarity-views.json directly to master. Branch protection now forbids that, so the rebuild has been silently not landing. The runs that appeared to pass only did so through the "no changes" early exit. The step now escalates: direct push, then pull --rebase and retry for a plain race, then fall back to a catalog-refresh/<date>-<sha> branch with a PR and auto-merge. If the repo also blocks Actions from opening PRs, it warns with a compare URL and exits 0 rather than failing. Errors are no longer swallowed. gh pr list dropped its || true, an unconfirmed PR after a successful branch push is a hard failure, and a failed auto-merge is a loud warning with the PR URL. The PR number is parsed from gh pr create's output URL rather than by re-listing, because listing immediately after creation races GitHub's PR index and can report a phantom failure. No retrigger loop: all four generated files sit outside this workflow's paths filters, so merging the catalog PR will not start another run. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 68fa07a3-7ce8-442f-a9e8-f6b1775d8a1f * Give the PR sweeper time to resolve a fork PR number Three runs on 7/22 aborted with "Could not resolve a trusted PR number from the workflow_run event". Fork PRs leave workflow_run.pull_requests[0].number empty, so the job falls back to looking the PR up by head SHA, and that lookup ran exactly once. PR #495 was created at 16:49:09Z and the report job queried at 16:49:37Z. Twenty-eight seconds. GitHub's commit-to-PR association index had not propagated yet; the same SHA resolves fine now. An earlier run the same afternoon hit the same empty value and resolved fine, which is what a propagation race looks like. The lookup now retries with backoff at 0, 3, 8 and 15 seconds and logs why each attempt came back empty. If it still cannot resolve, the job no longer exits 1. It warns, still posts the commit status, and returns. This does not weaken the gate: setStatus only needs the trusted head SHA, and the deterministic guardrails remain the authoritative merge check. Only the sticky comment is lost, and a red X on a healthy PR is worse than a missing comment. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 68fa07a3-7ce8-442f-a9e8-f6b1775d8a1f --------- Co-authored-by: soyalejolopez <88358406+soyalejolopez@users.noreply.github.com> Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 68fa07a3-7ce8-442f-a9e8-f6b1775d8a1f
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.
What & why
The card upvote count was baked into a static
resource-stats.jsonthat is only regenerated by a daily CI job (cron: 0 6 * * *). A fresh reaction wouldn't surface on the cards for up to ~24h, and today only one resource has a backing discussion, so the counter read as stale/misleading and looked like something you could vote on directly from the card (you can't).What this changes
Votesheader column and the orphaned.compact-votes/.ch-votesCSSWhat is intentionally preserved
upvotesis still loaded ingetStatsand still drives the Popular / Trending / Engaging sort logicDisplay-only removal — no data or sort behavior changes.