The wiki, in the console

A wiki for every repository you connect.

Each repository gets its own wiki, and each page names the commit it was written from. Pick a folder to pull another one out.

Start freeRead the docs
northpine/storefrontTypeScript9 areas, 12 pagesfrom 7a1c0d2Overview page
How it is written

Connect a repository. Its wiki writes itself.

No one has to start it, and no one has to keep it up. The wiki follows the default branch.

  1. 01

    A repository connects

    Through the IronBee GitHub App, with read-only access to its code and pull requests.

  2. 02

    It measures the code

    Folders, languages, the stack, commands, routes, and what imports and calls what, taken from the code itself.

  3. 03

    It writes the pages

    An overview, where to start, the architecture with its diagrams, and a page for every area of the code.

  4. 04

    It checks every source

    Each citation has to exist at the commit, and each diagram step has to name something real in the code.

Diagrams

The architecture, drawn from the code.

The wiki draws three kinds of diagram from what the code imports, calls and exposes. They are drawn again with every run, so they show the code that merged, not the code someone remembered.

The areas and how they depend on each othernorthpine/payments-api, 12 edges
Admin UIHTTP APIWebhooksChargesRefundsLedgerStripe clientStore
importsHTTP callsPoint at an area to see what it uses and what uses it.
Architecture page

Area map

Every area of the code as one box, with the dependencies between them: imports drawn solid, HTTP calls from one area to another dashed. The strongest are drawn, up to 60, and the rest are counted.

Useful for
  • Seeing what a change in one area can reach, before you make it.
  • Finding which part of the code calls which, without searching for URLs.
  • Spotting the area everything else leans on.
Architecture page

End-to-end flows

The main paths through the system. Each starts where work comes in, a route, a queue consumer or a scheduled job, and follows it across areas. Up to ten.

Useful for
  • Following a request from where it arrives to where it is stored, without opening every file on the way.
Taking a payment4 steps
  1. POST /v1/chargesinternal/http/routes.go L42
  2. amount and currency
  3. Chargesarea
  4. payment intent
  5. Stripe clientarea
  6. captured charge
  7. Ledgerarea
an areaa file or a definition
Every area page

Important flows

Up to ten flows on each area's page. Every step names a file, a function or a route and links to its lines at the commit.

Useful for
  • Learning how an area works before you open it, then jumping to the line that matters.
Refunding a chargeRefunds, 4 steps
  1. POST /v1/refundsinternal/http/routes.go L57
  2. charge id and amount
  3. refunds.Createinternal/refunds/create.go L24–61
  4. refund
  5. ledger.Reverseinternal/ledger/reverse.go L12–40
  6. reversal
  7. stripe.Refunds.Newinternal/stripe/refunds.go L9–33
a file or a definitioneach line opens on GitHub at the commit
How it stays current

It moves with the default branch.

Nobody schedules a rewrite or remembers to update a page. Merges start the runs, and a daily rebuild catches anything they missed.

v1

First build

from a91f3c0

The repository is connected. The whole default branch is read and every page is written.

v2

Two merges, one run

from 3f9e2a1

#415 and #412 merged close together. IronBee waits until merges stop for a while, never more than an hour, then writes one version from the newest commit.

v3

Small merge, small run

from 7d20b19

#418 changed only Refunds. Refunds is read again, and every other area keeps the reading it already has.

v4

Rebuilt from scratch

from 7d20b19

Once a day, if the branch moved since the last rebuild, the whole repository is read again from nothing. Weekly or manual if you prefer.

written from this commitquiet window: waits for merges to stopa version of the wikiScroll sideways for the whole history.

Only what merged

Open pull requests and other branches never change the wiki. It follows the default branch.

One run at a time

A merge that lands during a run waits for it, and everything that waited goes in the next one.

Refresh when you need it

Your team can start a run from the console, at most once an hour.

Who it helps

Day one in a codebase, without the tour.

The same pages serve whoever opens the code next.

New to the code

Where to start gives the reading order, the tools and versions you need, and the team's conventions, cited to the README and contributor guides.

Reviewing a change

Open the area a pull request touches: what it is for, what it depends on in the area map, and where to be careful before you approve.

Picking up an area

Files to open first, its important flows and its recent merged pull requests, on one page.

Code wiki FAQ

Code wiki, answered.

Which branch does it read?

The default branch. It is written again as pull requests merge into it.

How often is it written again?

After pull requests merge, and from scratch once a day by default, or weekly, or only when you ask. Your team can refresh it from the console once an hour.

What language is it written in?

The language your code reviews are written in, unless you pick another. Code, names and paths stay as they are.

Does it cost credits?

No. Code wiki is included on every plan and uses no credits.

Does it change my repository?

No. It reads the code with read-only access and posts nothing to GitHub.

What about secrets in the code?

Every page is scanned before it is saved and secrets are redacted. If the scan cannot run, no pages are written.

Can I leave folders out, or turn it off?

Yes. Turn it off for any repository, and add path patterns such as gen/** for folders it should skip.