Build lifecycle

Every bundle the Action uploads becomes a build, identified by its run ID. You can see each build’s status in the dashboard under Diagrams.

                 ┌──────────▶ superseded   (a newer push replaced it)
                 │
upload ──▶ queued ──▶ running ──▶ succeeded
   │                      └────▶ failed
   │
   └─────▶ duplicate   (identical plan, reuses an earlier diagram)

Status	Meaning	Counts toward monthly builds
queued	Accepted and waiting to render.	Only if it succeeds
running	Rendering.	Only if it succeeds
succeeded	Diagrams are ready.	Yes
failed	Rendering failed. The dashboard shows why.	No
superseded	A newer build for the same pull request and environment arrived before this one finished.	No
duplicate	The plan is identical to one already rendered, so its diagrams are reused.	No

Superseded builds

When a new build is accepted for a pull request, any older build for the same pull request and the same environment that is still queued or running is marked superseded. Only the latest push gets diagrammed, and you aren’t charged for pushes that came in quick succession.

Builds in different environments never replace each other.

Reused builds

Rendering is deterministic: the same bundle rendered by the same renderer version always produces the same diagrams. So when a build’s bundle is byte-for-byte identical to an earlier successful build of the same repository, Infragr.am reuses those diagrams:

• the build completes immediately with status duplicate;
• it doesn’t count toward your monthly builds or the daily allowance;
• with the default on-change comment mode, no new comment is posted.

This happens more often than you might expect: rebases, documentation-only commits, re-runs, and changes outside the Terraform root all give an identical plan.

When Infragr.am ships a new renderer version, the next build of each plan renders fresh, so improvements reach your diagrams without any change on your side.

Timing

The Action exits as soon as the build is accepted, and rendering happens afterwards, so your workflow’s run time doesn’t include it. The pull request comment appears when the build is accepted, and its link shows the diagrams once they are ready.