fetchOrgCalendar
The fetcher behind the organization calendar card.
An organization's weeks, each counting one kind of activity: pull requests merged by default.
Every week is an aliased search in one GraphQL request, which costs a single rate-limit
point for all of them. Like any search, a week counts what its token can find, private
repositories included where the token reads them.
fetchOrgCalendar(options, config: CardConfig): Promise<OrgCalendarData>| Option | Type | Required | What it is |
|---|---|---|---|
org | string | undefined | yes | — |
count | "issues_closed" | "issues_opened" | "prs_merged" | "prs_opened" | undefined | no | — |
weeks | number | undefined | no | Weeks to cover, ending today; clamped to 1–ORG_CALENDAR_MAX_WEEKS, which is also the default. |
Returns Promise<OrgCalendarData> — The weeks, oldest first.
The weeks
Section titled “The weeks”Each week is seven days ending on a weekday of today’s, so the newest week ends today and is never a stub. Every end is a UTC date, because a date is all a search qualifier reads.
What it costs
Section titled “What it costs”Each week is an aliased search on one GraphQL request, and GitHub charges that request a single
rate-limit point however many weeks ride on it. Each search still adds to the time GitHub takes to
answer, about half a second for a busy organization, so past about four months a request outlasts
GitHub’s ten-second limit, which answers with a 502 that the fetcher throws as an upstream
error. The calendar stops at two months to keep well clear of it.
What a search can see
Section titled “What a search can see”A search answers what its token is allowed to find, so a token with access to the organization’s private repositories counts those too.
A token that may not read issues is answered with pull requests rather than an error. Each week asks
for the first thing it matched, and an issue count that matched a pull request is refused as
forbidden instead of drawn.