Repository navigation
Which is canonical: -REPO- or rsr-template-repo? (both claim it, and share one SonarCloud project) #8
Description
Activity
Closing as invalid — my error. There is only one repository.
hyperpolymath/-REPO-is not a repository. It is a GitHub rename redirect pointing at this repo. Decisive evidence:Queried -REPO-Queried rsr-template-repofull_namereturnedhyperpolymath/rsr-template-repohyperpolymath/rsr-template-repoRepository id1306804488 1306804488 created_at2026-07-20T16:30:10Z 2026-07-20T16:30:10Z Same numeric ID, same creation timestamp, same canonical name. Every ref matches byte-for-byte —
HEAD,main, botharchive/*branches and all sevenrefs/pull/*/head. I compared this repository against itself, via its old name, and reported it as two competing canonical templates. The "byte-identical descriptions" I cited as suspicious were byte-identical because they are one description.I should have checked
full_namebefore opening this. Sorry for the noise.What actually happened — already diagnosed and fixed
The cause is documented in this repo's own
.github/settings.yml, in a warning banner added when it was fixed:This file previously read
name: "{{REPO}}". probot/settings applies it on every push to the default branch, so it submitted the literal string{{REPO}}as the repository name. GitHub sanitises an invalid name by collapsing each run of illegal characters to a dash —{{REPO}}became-REPO-. The template renamed itself on every push, its old URL 404'd, and it was mistaken for a deleted repository.So
-REPO-was never a second template, and nobody created it deliberately — the template renamed itself, repeatedly. The fix removed all identity keys (name,description,homepage,private) from the probot file and banned them categorically, for two stated reasons: "Use this template" copies the default branch verbatim without runningjust init, so placeholders reach children unrendered; and identity is not shareable, since the template is public while children default private.Nothing needs deleting. GitHub retains renamed paths as permanent redirects; a redirect is not a repo and cannot be deleted. It is harmless.
On the sonar key — no change needed
sonar.projectKey=hyperpolymath_rsr-template-repois this repo's own correct key. My earlier claim in metadatastician/IDApTIK#33 that this repo carried a stale copied key was wrong, and no change was made here.One genuine residue, needing owner access
The SonarCloud project
hyperpolymath_rsr-template-repostill has the display name-REPO-— captured during the window when the repo was misnamed. The key is right; only the display label is wrong. Cosmetic, but it is the last visible trace of the incident, and renaming it needs a token I do not have.For the record, the earlier "check before deleting" guidance was about a local clone, not this redirect: that clone held
archive/pre-snapshot-main(b203e12) and an incident branch that existed nowhere else, so they were pushed to this repo and verified byls-remotebefore the clone was removed. Both are still here — confirmed just now:47e2525… refs/heads/archive/incident-revert-ddraig-pages b203e12… refs/heads/archive/pre-snapshot-mainThe lesson was "verify containment before deleting a clone", not "never delete anything".
Surfacing a question that came out of an estate-wide SonarCloud config sweep, but which is really about repository identity rather than SonarCloud.
The question
hyperpolymath/-REPO-andhyperpolymath/rsr-template-repoboth claim to be the canonical RSR template, and they share one SonarCloud project.Verified via the GitHub API:
-REPO-rsr-template-repoisTemplatesonar.projectKeyhyperpolymath_rsr-template-repohyperpolymath_rsr-template-repoBoth are live, both are marked as templates, both were pushed the same day, and both point at the same SonarCloud project — whose display name is
-REPO-while its key ishyperpolymath_rsr-template-repo.Which one is canonical? I can't tell from outside, and it matters more than the sonar key does: repos instantiated from the wrong one inherit the wrong scaffolding.
Why the sonar key can't be fixed without that answer
For
rsr-template-repo,hyperpolymath_rsr-template-repois its own correct key — no fix needed. For-REPO-, it's the copied-template problem seen across the estate, but the natural replacement (hyperpolymath_-REPO-) is a strange key, and if-REPO-is a scaffold placeholder it may not warrant a SonarCloud project at all.So unlike the other repos in this sweep, this one needs a decision, not a patch. Options as I see them:
rsr-template-repois canonical —-REPO-gets its own key or has its SonarQube workflow removed; consider archiving it to stop accidental instantiation.-REPO-is canonical — it should ownhyperpolymath_rsr-template-repo(rename the project or repoint the key), andrsr-template-reponeeds its own.Correction to an earlier claim of mine
In metadatastician/IDApTIK#33 I listed
rsr-template-repoamong the repos "carrying a stale template key". That was wrong — it's the template, so that key is correctly its own. Only-REPO-is in question. Apologies for the noise.Context: what was fixed in the same sweep
Same copied-key fault, unambiguous, PRs open or merged:
chronicles-of-slaviawas already fixed by someone in the interim.v3-templateris archived, so its malformed key is moot.Separately and more urgently:
SONAR_TOKENis set on only two repos in the whole estate (boj-server,cicd-squabbler). Everywhere else the scan fails at authentication and submits nothing, so no SonarCloud analysis is actually happening.hyperpolymathis a User account, not an Organization, so there is no org-level secret to inherit — each repo needs its own. Fix keys before adding tokens: a valid token plus a copied key reports silently into the wrong project.