Environments

A run says where it ran — staging, production, dev — in its environment, a badge on the Runs list and on the run’s page. The project keeps a list of its environments, which Plune suggests when a run is launched and in the Runs filter.

The list suggests; it does not restrict. A run can report any environment, from the dashboard or from CI, and one outside the list is accepted as it came and marked «not in the list».

The list

Settings → Environments, right after Configurations, lists the project’s environments — «Environments · 3» — each with its runs and the latest of them: «48 runs · last 2 hours ago».

• Add environment — a Name, then Add. A name runs already report comes in with those runs counted.
• Archive moves an environment under Archived — «Archived · 1», with «9 runs · archived Oct 3, 2026» — where Restore brings it back. An archived environment is not suggested any more; the runs that reported it keep the value, and a run that reports it is still accepted.
• Rename — below.
• Seen in runs, not in the list — the values runs reported that the list does not hold, each with its runs and Add to list. They stay on their runs as reported and are marked «not in the list».

A name is matched without regard to case or to the spaces around it: «staging», «Staging» and «staging » are one environment — in the list, in its counts, and in what is «not in the list». The list holds up to 100 environments, the archived ones included; a name is 1 to 64 characters.

In a project that had runs before the list existed, the list starts filled: the environments its runs reported, up to 100, the most used first, each under the spelling most of its runs carry. The rest wait under «Seen in runs, not in the list». No run was rewritten for it.

Only an owner of the project changes the list. A member and a reader see it, with «Only an owner of the project can change these.» and nothing to press.

Rename

Rename opens Rename environment — «staging · 48 runs. Every run of it takes the new name.» — with the New name and Rename. The rename rewrites the environment of every run of the project that carries the old name in any spelling, runs in the Bin included, and a dashboard widget filtered by the old name takes the new one. Results, verdicts and a case’s history do not change: none of them reads the environment.

A new name that runs already report outside the list would make the two one environment, and that cannot be split back. So the dialog asks first, and says what it makes:

«qa-2» is already used in 3 runs outside the list. After the rename they become one environment of 51 runs; it cannot be split back.

Merge renames and merges; Cancel leaves both as they were. A new name the list already holds — an archived one counts — is refused.

A run’s environment at launch

In the Manual run dialog — New run ▾ › Manual run… on Runs, or Run manually in the cases tree (Starting one) — Environment · optional takes environments as chips:

• On focus it offers the project’s live environments under In this project, each with its runs, five at a time; typing narrows them.
• A value that is none of them is offered as Use “qa-2”, not in the list, and the dialog says so under the field: «qa-2 is not in the project’s list: the run keeps it as typed and it is marked «not in the list».»
• Enter takes the highlighted row, or what you typed; Backspace in an empty field takes back the last chip.

One environment, or none, is one run, as it always was. On the run’s page an environment outside the list carries the mark on its badge: qa-2 · not in the list.

A plan’s Launch run keeps one environment as plain text: a plan launches one run.

Launch on several environments

Two environments or more make a run for each, and the runs are one group. The field becomes Environments · optional, and the dialog says what comes: «12 cases → 3 runs «Manual · …» · one per environment», and under the field «One run per environment; together they are one group.» It then asks When does the group pass? — the three strategies, Realistic picked — with «The rule is kept on the group and can be changed on its page; the change goes to the audit log.» The button reads Launch · 3 runs.

• Launch · 3 runs starts the three and opens the group’s page.
• Save keeps the three scheduled — nobody marks a case until someone launches them — and the notice leads to the group: Open the group.

Each run of the group is a run like any other: a row on the Runs list, a page of its own, its own environment, and its own key — so the CI job of each environment can report into its run with PLUNE_RUN=<key> (The command with the key). The runs share the cases, the title, the fields and the configurations. A run of the group says so beside its environment: Part of group · 3 environments, a link back to the group.

A launch takes at most 10 environments — past that, «A launch takes at most 10 environments — remove some to launch it.» Each run takes its place in the project’s daily run quota, and a launch takes all its places or none: with two places left, three environments are refused and no run is made.

With configurations

With configurations picked as well, every run of the group gets the same combinations: three environments × four combinations × 120 cases are 1 440 results in three runs. The line says «12 cases × 4 configurations → 3 runs «…»», and the button still counts the runs: Launch · 3 runs.

An environment’s status reads all its combinations together: a failure on one combination fails the environment, and a combination with a case not run makes it broken.

The group’s page

The group opens at /runs/groups/<id>. Its head says «3 environments · automated · 2 hours ago», its title, and the group’s status.

The card under the head says the status in words — «Failed · realistic: 1 of 3 environments failed» — then the rule — «Strategy: Realistic — passed only if every environment passed.» — and the results of all its runs together: «7 passed · 1 failed · 1 skipped · 9 results in 3 runs».

Under Environments · 3, a row per environment: its status, its counts — «1 of 3 failed · 2 passed», «3 of 3 passed» — how long it took, and Open run →. The whole row opens its run: «A row opens its run in one click.»

Activity says who launched the group and with which rule — «John Doe started 3 runs on staging, production, dev · strategy realistic» — and every change of the strategy since.

A run of the group deleted to the Bin stays in its row, marked in the Bin, without a link, and counts as broken; its results leave the totals. Deleting the run that failed does not make a group pass.

When a group passes

An environment’s status

Each environment is its run’s status — the first line that fits:

The run	The environment
In the Bin	broken
Scheduled, or still under way	running
A failed result, one or more	failed
A broken or blocked result; or the run was stopped with Stop run (terminated); or an expected case was not run — in the run, or in any one of its combinations, a combination with no result at all included	broken
A passed result	passed
Only skipped or muted results, or none	skipped

A muted case’s failure neither fails an environment nor passes it (A muted case’s failure).

The three strategies

While any environment is running, the group is Running, whatever the strategy: there is no early verdict. Once none is:

Strategy	The group passed	The group failed
Realistic	every environment passed	any environment did not pass
Optimistic	at least one environment passed	no environment passed
Pessimistic	any environment did not fail	every environment failed

How each mix of environments comes out:

Environments	Realistic	Optimistic	Pessimistic
All passed	passed	passed	passed
All failed	failed	failed	failed
Passed and failed	failed	passed	passed
Passed and broken or skipped, none failed	failed	passed	passed
Failed and broken or skipped, none passed	failed	failed	passed
Only broken or skipped	failed	failed	passed

Pessimistic is the lenient one when nothing passed

Optimistic and Pessimistic agree whenever every environment passed or failed. They part only when no environment passed and some are broken or skipped: there Optimistic fails the group and Pessimistic passes it.

Change the strategy

Change strategy, on the group’s page, offers the three rules, the saved one marked «· current», and says what the status becomes with the one you pick — «With Optimistic the group becomes Passed: 2 of 3 environments passed.» — and that «The group’s summary status is recalculated by the new rule. The change is written to the audit log: who, when, realistic → optimistic.» Change strategy saves it. The page then says «Strategy changed to optimistic — the group’s status was recalculated. The change is in the audit log.», and Activity gets «John Doe changed strategy realistic → optimistic».

The status is never stored: it is worked out from the runs each time the page is read, so a changed strategy is simply the next read, and so is a run that finished meanwhile.

Filter Runs by environment

Environment, above the Runs list, narrows it to the runs that reported one environment, with the project’s live list suggested. The filter goes into the page’s address — ?environment=staging — and nothing matching says «No run reported this environment.». The field is there once the project’s list holds a live environment.

The filter finds the name as it is written: a run that reported «Staging» is not under «staging». A rename brings the spellings together.

Who may do what

	Owner	Member	Reader
See the list, a group and its page	yes	yes	yes
Add, rename, archive and restore environments	yes	no — 403	no — 403
Launch on several environments	yes	yes	no — 403
Change a group’s strategy	yes	yes	no — the button is not there, and the API answers 403

The API

• GET /v1/environments — { "environments": [{ "id", "name", "archivedAt", "runs", "lastRunAt" }], "seen": [{ "name", "runs", "lastRunAt" }] }. seen names up to 100 values, the most recent first.
• POST /v1/environments with { "name": "staging" } answers 201. A name the list holds already, in any case, archived or not, answers 409, and so does a list of 100.
• PATCH /v1/environments/{id} with { "name": "stage" } renames it and rewrites the runs. Onto a name runs report outside the list it answers 409 with mergeRuns, how many runs carry it; the same call with "merge": true merges them. One rename rewrites at most 50 000 runs: past that, 413 before anything is written.
• POST /v1/environments/{id}/archive and /restore. These four writes are an owner’s: anyone else gets 403.
• POST /v1/run-groups — the body of a run start (title, kind, the expected cases, custom, assignment, schedule) without environment and externalKey, plus environments, 2 to 10 names, none twice by the matching rule, and strategy — realistic, optimistic or pessimistic. It answers 201 with { "group", "runs" }, each run with its own externalKey. One environment, eleven, a name twice or an unknown strategy answer 400; a reader, 403; a day that cannot take every run, 429, and nothing is made.
• GET /v1/run-groups/{id} — the group, its runs (each with its environment, counts, total, durationMs, deleted and status), the group’s status, statusBy — the status under each of the three strategies — and totals. A group that is not in the project answers 404.
• PATCH /v1/run-groups/{id} with { "strategy": "optimistic" } answers the group as read after it, and the audit log gets one entry with the strategy before and after; the same strategy again writes nothing. GET /v1/audit/run_group/{id} reads that log — the page’s Activity.
• GET /v1/runs/{id}/summary answers group — { "id", "size" } for a run of a group, null for a run of its own.
• GET /v1/runs?environment=staging — the runs that reported that environment, the name as written.