GitHub får stjärnhistorik via API – rätta diagrammet i din AI-byggda dashboard

Nyheten: historik utan en lista över personer

Den 4 september 2026 presenterade GitHub ett REST-API för aggregerad stjärnhistorik utan enskilda stjärnmarkerares identiteter. GitHubs lanseringsnotis pekar på verktyg och integrationer som tidigare följde stjärnutveckling. För dig som tar över en AI-byggd dashboard är uppgiften att ersätta adaptern och kontrollera diagrammets betydelse.

Börja med att söka efter anrop till stargazers och fält som starred_at i projektet. Anteckna vilka vyer som använder resultatet, vilka mellanlager som sparar det och vad axlarna heter. Om samma array driver både en veckograf och en siffra med etiketten ”Stjärnor nu” behöver de vyerna få separata datakontrakt innan du byter endpoint.

Läs svaret före kodändringen

Enligt GitHubs REST-dokumentation, kontrollerad 6 september 2026, används GET /repos/{owner}/{repo}/stargazers/history. Svaret är en array med week, total och days. Veckorna kommer nyast först, även inom varje sida. Nollveckor finns med. Dagarrayen börjar på söndag och räknar skapade stjärnor. Vecko- och dygnsgränser garanteras inte följa UTC.

Spara ett råsvar som fixtur tillsammans med endpoint, parametrar, API-version och hämtningstid. Behåll transport, adapter och diagram som tre skilda steg. Då kan du prova om ett bakvänt diagram beror på sidordningen eller på att diagramkomponenten själv sorterar etiketter. Ge kodagenten råsvaret som underlag, inte enbart en skärmbild av den gamla kurvan.

En adapter med ett smalt ansvar

Exemplet tar redan hämtade sidor i API-ordning och skapar veckopunkter från äldst till nyast. Det gör ingen daglig datumrekonstruktion och beräknar inget aktuellt stjärnantal. Fältnamnet created är vårt eget val för diagrammodellen; det är inte ett nytt GitHub-fält. Funktionen förutsätter validerade svar med unika veckonycklar.

function toWeeklySeries(pages) {
  return pages.flat().map(({ week, total }) => ({
    weekKey: week,
    created: total
  })).reverse();
}

Vänd den sammanfogade serien en gång. Om du vänder varje sida för sig kan punkterna inom en sida se korrekta ut medan övergången mellan sidor hoppar bakåt. Lägg inte till filter(point => point.created): en nollvecka behöver finnas kvar för att avståndet mellan händelser ska synas. För en löpande totalsumma bör du först ange vilken startpunkt och täckning summan har.

Gör schemavalidering före adaptern. Som lokalt kontrakt kan du kräva en array, numeriska veckonycklar, icke-negativa heltal och en dagarray med sju positioner. Vid fel ska hämtningen markeras som misslyckad; om du ersätter ett trasigt svar med en tom array kan gränssnittet visa ”ingen aktivitet” trots att det saknar data. Fler sätt att avgränsa granskningen finns i guiden till kodgranskning.

Testa sidgränsen och nollveckan tillsammans

Här är en syntetisk fixtur med två sidor. Veckonycklarna är enbart sorteringsvärden för testet, inte riktiga datum. Kör exemplet i Node som en separat .mjs-fil tillsammans med funktionen ovan. Förväntningen är uttrycklig: den äldre punkten först, nollveckan kvar och den nyare punkten sist.

import assert from 'node:assert/strict';
const pages = [
  [{ week: 300, total: 5 }, { week: 200, total: 0 }],
  [{ week: 100, total: 2 }]
];
assert.deepEqual(toWeeklySeries(pages), [
  { weekKey: 100, created: 2 },
  { weekKey: 200, created: 0 },
  { weekKey: 300, created: 5 }
]);
assert.deepEqual(toWeeklySeries([[]]), []);
assert.equal(pages[0][0].week, 300);

Det sista påståendet kontrollerar att indata inte har vänts på plats. Lägg också ett integrationstest runt hämtaren: låt den första simulerade sidan peka vidare och kontrollera att nästa svar hamnar i samma dataserie. Prova ett fel på den andra sidan och kräv ett fel- eller ofullständighetsläge i vyn. Ett lyckat första anrop får inte ensamt sätta etiketten ”hela historiken”. Se guiden till testning av AI-genererad kod för hur du gör förväntningarna oberoende av implementationen.

Paginering behöver en synlig slutpunkt

I REST-dokumentationen, kontrollerad 6 september 2026, är per_page högst 30 och page högst 100. Sidorna går bakåt mot projektets skapelsevecka. För mekaniken visar GitHubs pagineringsguide hur nästa sida anges via svarshuvudet Link.

Låt hämtaren följa nästa länk när den finns och spara hur många sidor som hämtats. Sätt dessutom ett eget anropstak för testkörningen. Om taket nås ska resultatet markeras som avkortat och intervallet anges i diagrammet. Blanda inte ett sådant lokalt stopp med att servern har bekräftat slutet på serien. Testa båda fallen: sista sidan utan nästa länk och avbruten hämtning med fler sidor kvar.

Skilj datumetiketten från mätvärdet

Börja med en veckovy som behåller veckonyckeln. Undvik att låta agenten automatiskt skapa sju UTC-datum och presentera dem som exakta kalenderdygn. Om du behöver en dagvy, dokumentera först hur datum ska tolkas och prova en gräns där lokal tid och UTC ger olika datum. Ett skärmbildstest kan låsa den beslutade etiketten, men det bevisar inte serverns tidszon.

GitHubs count-endpoint, kontrollerad 6 september 2026, ger aktuellt antal och utesluter borttagna stjärnmarkeringar. Behandla därför en summering i veckografen som ”skapade stjärnor i hämtat intervall”. Skriv inte ”stjärnor nu” ovanför samma summa. Skillnaden ska finnas både i testets förväntade etikett och i den färdiga vyn.

Ge kodagenten en kontrollerbar beställning

Byt dashboardens historikadapter till den dokumenterade
stargazers/history-strukturen. Behåll nollveckor och sammanfoga
sidor innan ordningen vänds. Separera aktuellt antal från
skapade stjärnor. Lägg test för sidgräns, tomt svar, avbruten
hämtning och datumetikett. Visa diff och testresultat.

Godkänn ändringen när det sparade råsvaret går genom validering och adapter, testet över sidgränsen passerar och gränssnittet skiljer tom historik från hämtningsfel. Kontrollera därefter en verklig hämtning i din egen miljö. Exemplen här är lokala adapterprov, inte ett genomfört test mot ditt repository. Spara före- och efterbild tillsammans med den commit som ändrade adaptern så att nästa granskare kan se både kodskillnaden och diagrammets nya betydelse.