Run details

GhostWorkspace

CI Pipeline Executions
- Current executionSucceeded
  chore/limit-characterisation
- Runs and Agents
- Configuration
- Self-Healing CI
- Project Graph
- Circular DependenciesEnterprise
- Resource Usage
- Analysis
- ConformanceEnterprise
Runs

Insights

Compare tasks
Analytics

Added tests pinning what a host limit does to a site Limits are about to be replaced, and nothing here proved they worked. Every existing test replaces the limit service with stubs and then checks that Ghost called them, which stays true however the limits are implemented underneath, including when they are not implemented at all. These configure limits the way a host does and assert what a caller receives. All four kinds refusing and allowing: a feature switched off, a count reached, a value not on a list, and an allowance for a billing period. The numbers a counted limit puts in its message. The block handed to the browser so it can gate the same way. The shape an integration parses, which is not the shape it looks like: the limit's own sentence arrives in the error's context while the message carries the endpoint's generic wording. Then the ones nobody has written down. A limit this build has never heard of is ignored. A known limit spelled in another case loads with none of its settings. A periodic limit with no billing period to count against is dropped entirely, so a site that is paying for that limit is not actually held to it. Each of those leaves a site less limited than its host asked for, silently. The only thing stubbed is the call that would leave the process to reach Stripe. Setting a limit is otherwise setting configuration and nothing else: the one wrinkle, that limits are read during boot and must be re-read when a test changes them, is now behind a single helper rather than a reason to reach for a stub. The browser test fixture takes any host setting rather than the handful somebody happened to need. ref https://linear.app/ghost/issue/BER-3797

nx run @tryghost/e2e:test:fixtures

Succeeded

4 CPU cores

read-write access token used

b930b7ee30509

100%

Cache hits

4 of 4 tasks used cache.

Protect cache integrity with sandboxing

Get faster results

Learn how to enable distribution.

Atomizer enabled

3 groups of tasks optimized.

© 2026 - Nx Cloud

Terms of Service Privacy Policy Changelog Status Docs Contact Nx Cloud Pricing Company @NxDevTools

GhostWorkspace