How to disable performance report enabled in #36077

[DavidTelenko]

I get quite lengthy markdown dump on each e2e run in CI which mixes in between my own messages which present links to reports. It causes confusion. Is there any way of disabling this feature via env variables or nx flags?

[christianalberto]

To disable the performance report in your CI, just override the GitHub Actions variable by adding GITHUB_STEP_SUMMARY: '' to your workflow step:

- name: Run E2E Tests
  env:
    GITHUB_STEP_SUMMARY: ''
  run: npx nx run-many -t e2e

If you also want to hide the Nx Cloud recommendations from the console output, add this variable:

NX_NO_CLOUD=true

[wimbarelds]

If you also want to hide the Nx Cloud recommendations from the console output, add this variable:
NX_NO_CLOUD=true

That doesnt actually disable the

Recommendations:
    - Drastically reduce your run duration by sharing a cache across your team and CI → https://nx.dev/ci/features/remote-cache?utm_source=nx-cli&utm_medium=cli&utm_campaign=performance-report&utm_content=remote-cache.
    - Speed up or split the longest tasks on the critical path:
        app_1:build    12.3s

Message.

[edit] Seems that this was fixed in 23.1.1

[DavidTelenko]

@christianalberto, yep already did similar thing, but overwrote it only for nx command like this GITHUB_STEP_SUMMARY="" yarn nx ... (I need other scripts in CI job to output to summary). This works, but feels more like a hack to me, and also won't disable TUI result stats.

I wish we could have some sort of NX_DISABLE_PERF_STATISTICS=true (or more even more precise vars to control each aspect of this process).

[official-burak]

There is no native flag as of 23.1.1 — PerformanceLifeCycle is registered unconditionally, and nothing reads an NX_* variable to suppress it:

// packages/nx/src/tasks-runner/run-command.ts, createLifeCycles()
if (process.env.NX_PERF_LOGGING === 'true') { lifeCycles.push(new TaskTimingsLifeCycle()) }
if (process.env.NX_PROFILE) { lifeCycles.push(new TaskProfilingLifeCycle(process.env.NX_PROFILE)) }
lifeCycles.push(new PerformanceLifeCycle(taskGraph, { skipNxCache, nxJson }));  // no gate

The two lifecycles above it are env-gated; this one isn't. summary() returns null only when zero task timings were recorded, so there's no config path either.

What's more useful is that the report has three separate output surfaces with different gates, and that's what decides which of your remaining complaints is fixable today. All in performance-life-cycle.ts:

1. The GitHub job summary markdown — the formatReportMarkdown you linked. Three conditions, all skippable:

const summaryPath = process.env.GITHUB_STEP_SUMMARY;
if (
  process.env.GITHUB_ACTIONS !== 'true' ||
  !summaryPath ||
  process.env.NX_TASK_TARGET_PROJECT
) {
  return;
}

2. The console print — ungated, in a finally so it runs on success and failure:

export function flushPerformanceReport(): void {
  ...
  console.log(formatReport(summary));
  writePerformanceReportToGitHubActions(summary);
}

3. The TUI exit popup:

export function getPerformanceReport(taskCount: number) {
  if (!isTuiEnabled() || taskCount <= 1) { return undefined }
  return getPerformanceSummaryPayload() ?? undefined;
}

Two things follow from that, and both are worth knowing before you spend time on it.

NX_TUI=false will not remove the TUI result stats — it relocates them. isTuiEnabled() is process.env.NX_TUI === 'true', and when it's false getPerformanceReport returns undefined, which leaves the report unconsumed for flushPerformanceReport() to console.log to the terminal instead. The popup and the terminal print are two renderings of the same payload, and exactly one of them always happens. There is no combination of environment variables that produces neither.

NX_TASK_TARGET_PROJECT gates the summary write, but don't use it for this. It looks like the scalpel you want — it suppresses only surface 1 and leaves GITHUB_STEP_SUMMARY intact for your own scripts — but it's overloaded as the "which project am I" signal. Besides nx exec's already-running guard, it's read by packages/next/plugins/with-nx.ts, packages/vite/plugins/nx-tsconfig-paths.plugin.ts, and the rspack/webpack/rollup option normalizers. Setting it to a value that isn't a real project name at the top level will make those resolve against a project that doesn't exist.

So your GITHUB_STEP_SUMMARY="" yarn nx ... prefix is the correct answer today, and I'd stop treating it as a hack. It's a per-process environment override scoped to exactly one command, which is precisely what the Node wrapper script proposed upthread does — same semantics, one line instead of a file to maintain. It leaves the variable intact for the other steps in the job, which was your actual requirement.

For the recommendations block, NX_NO_CLOUD=true does work, and it's worth knowing why it's reliable rather than incidental:

export function isNxCloudDisabled(nxJson: NxJsonConfiguration): boolean {
  return process.env.NX_NO_CLOUD === 'true' || nxJson.neverConnectToCloud;
}

The env var and neverConnectToCloud in nx.json are equivalent inputs to the same check, so if you want it permanent rather than per-invocation, set neverConnectToCloud: true and drop the variable.

If you do file the NX_DISABLE_PERF_STATISTICS request, the implementation is small and worth saying so in the issue: one gate on the lifeCycles.push(new PerformanceLifeCycle(...)) line kills all three surfaces at once, because both the popup and the terminal flush read from activePerformanceLifeCycle, which is only set by that lifecycle's constructor. A single early return in createLifeCycles covers the console print, the job summary, and the TUI popup with no other changes.

Verified against main at 7c5c1fb (23.1.1).

[Asvarox]

With multiple jobs this causes a flood of potentially irrelevant summaries making the GH Actions feature a bit useless. Haven't checked, but the workaround might suppress summaries generated by the scripts run through NX within that invocation/step. It's also quite cryptic