# Ordering And Flakes

Control spec ordering and manage flaky specs, Serial, Ordered containers with...

- Repository: https://github.com/onsi/ginkgo (9071 stars)
- Category: Engineering
- License: MIT
- Last updated: 2026-10-09
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add onsi/ginkgo --skill ordering-and-flakes -g -a claude-code -y`
Codex: `npx skills add onsi/ginkgo --skill ordering-and-flakes -g -a codex -y`
Cursor: `npx skills add onsi/ginkgo --skill ordering-and-flakes -g -a cursor -y`
Gemini CLI: `npx skills add onsi/ginkgo --skill ordering-and-flakes -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add onsi/ginkgo`

## Description

Control spec ordering and manage flaky specs, Serial, Ordered containers with BeforeAll/AfterAll/ContinueOnFailure, OncePerOrdered, SpecPriority, plus FlakeAttempts/--flake-attempts, MustPassRepeatedly, --repeat, and --until-it-fails. Use when specs must run in a fixed order, you need once-per-group setup, you're combining Serial+Ordered, a spec is flaky, or you want to hunt order-dependence with --until-it-fails -p --randomize-all.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Ordering and flakes

Two topics that share a root cause: specs that aren't truly independent (`ginkgo:overview`). Ordering decorators let you *declare* a dependency on purpose; flake controls let you *manage or expose* one. Docs: <https://onsi.github.io/ginkgo/#serial-specs>, <https://onsi.github.io/ginkgo/#ordered-containers>, <https://onsi.github.io/ginkgo/#repeating-spec-runs-and-managing-flaky-specs>.

## Serial: opt out of parallelism

`Serial` (container or subject) guarantees a spec never runs in parallel with anything else. Under the hood Ginkgo runs serial specs **last, on process #1**, after every other process has finished its suite. Reach for it sparingly.  OK for benchmarks, resource hogs, or specs that put an external resource into a known-bad state - but not OK as a band-aid for order-dependence or poorly isolated code/specs.

```go
Describe("Something expensive", Serial, func() {
	It("is a resource hog that can't share the box", func() { ... })
})
```

→ `ginkgo:decorators`, `ginkgo:parallelism`.

## Ordered: run specs in definition order

`Ordered` (container only) guarantees its child specs run **sequentially, in written order, on one process**, so they may legitimately mutate shared closure state. They can still parallelize against specs in *other* containers; only the inner order is pinned.

```go
Describe("checking out a book", Ordered, func() {
	var libraryClient *library.Client
	var book *books.Book

	BeforeAll(func() {                         // once, before the first spec
		libraryClient = library.NewClient()
		Expect(libraryClient.Connect()).To(Succeed())
		DeferCleanup(libraryClient.Disconnect) // context-aware: behaves like AfterAll
	})

	It("can fetch a book", func() { book, _ = libraryClient.FetchByTitle("Les Miserables") })
	It("can check it out", func() { Expect(library.CheckOut(book)).To(Succeed()) })
	It("is then out of stock", func() { ... })

	AfterAll(func() { ... })                   // once, after the last spec
})
```

The rest: https://github.com/onsi/ginkgo/blob/HEAD/plugins/ginkgo/skills/ordering-and-flakes/SKILL.md