Skip to content

fix(metrics): FLOX_DISABLE_METRICS not honoured - #209

Merged
dcarley merged 3 commits into
mainfrom
fix/eco-104-disable-metrics-default
Jun 24, 2026
Merged

fix(metrics): FLOX_DISABLE_METRICS not honoured#209
dcarley merged 3 commits into
mainfrom
fix/eco-104-disable-metrics-default

Conversation

@dcarley

@dcarley dcarley commented Jun 24, 2026

Copy link
Copy Markdown
Contributor

refactor(metrics): FLOX_DISABLE_METRICS dupe set

The action's sole entry point is run() (action.yml declares only
main: dist/index.js), and run() exports FLOX_DISABLE_METRICS at the top
of every invocation — before the nix/package branch — so it already covers
every install path. getDownloadUrl() is reached only on the package path,
and always after run() has exported the same value, so its own
FLOX_DISABLE_METRICS export was dead duplication left behind when the
export was hoisted into run().

Remove that export so there is a single source of truth. No behavior change:
run() still exports unconditionally here — the guard that fixes the
workflow-env override bug lands in the following commit. getDownloadUrl()
keeps its RETRIES/PROXY exports, which are specific to the package path,
and its test is narrowed to the RETRIES assertion it still covers.

fix(metrics): FLOX_DISABLE_METRICS conditional

Callers who set FLOX_DISABLE_METRICS: "true" at the workflow env: level
were silently having their setting overwritten. The disable-metrics input
defaulted to "false", and core.exportVariable writes to $GITHUB_ENV,
which the runner folds into the job's global environment — overwriting any
prior value. This meant the obvious way to opt out of metrics was broken.

Guard the single run() export so it only fires when the caller actually
passes the input. When disable-metrics is unset (the new default of ""),
the action leaves FLOX_DISABLE_METRICS untouched — at whatever value the
caller already set, or absent, in which case the flox CLI applies its own
default (disabled/false by its #[serde(default)] bool).

action.yml default changed from "false" to "" and the description
expanded to explain the new semantics. README.md inputs table updated to
match. dist/index.js rebuilt to match.

Tests cover both branches of the run() guard: an unset input leaves
FLOX_DISABLE_METRICS untouched (the regression), and an explicit value is
still exported. 64 tests pass, statement/line coverage at 100%.

--

I'll cut a release and bump our usage once this is merged.

@github-actions github-actions Bot added the team-developer-support Work related to the developer support team label Jun 24, 2026
@dcarley
dcarley requested review from devusb, garbas and gilmishal June 24, 2026 10:46
@dcarley dcarley changed the title fix(metrics): FLOX_DISABLE_METRICS conditional and dupe fix(metrics): FLOX_DISABLE_METRICS not honoured Jun 24, 2026
@dcarley
dcarley enabled auto-merge (rebase) June 24, 2026 14:22
@dcarley
dcarley disabled auto-merge June 24, 2026 14:23
dcarley and others added 3 commits June 24, 2026 15:30
Running npm install in the flox dev shell (npm 11.6.2 / Node 24)
re-resolved the dependency graph and recorded "peer": true metadata on
three devDependencies that the older npm which last wrote the lockfile
did not annotate. No package versions, additions, or integrity hashes
changed, and the published action (bundled dist/index.js) is unaffected.

Forge-Agent: forge-implement (03fbd38a)
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The action's sole entry point is `run()` (`action.yml` declares only
`main: dist/index.js`), and `run()` exports `FLOX_DISABLE_METRICS` at the top
of every invocation — before the nix/package branch — so it already covers
every install path. `getDownloadUrl()` is reached only on the package path,
and always after `run()` has exported the same value, so its own
`FLOX_DISABLE_METRICS` export was dead duplication left behind when the
export was hoisted into `run()`.

Remove that export so there is a single source of truth. No behavior change:
`run()` still exports unconditionally here — the guard that fixes the
workflow-env override bug lands in the following commit. `getDownloadUrl()`
keeps its `RETRIES`/`PROXY` exports, which are specific to the package path,
and its test is narrowed to the RETRIES assertion it still covers.

Refs: ECO-104
Forge-Agent: forge-implement (03fbd38a)
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Callers who set `FLOX_DISABLE_METRICS: "true"` at the workflow `env:` level
were silently having their setting overwritten. The `disable-metrics` input
defaulted to `"false"`, and `core.exportVariable` writes to `$GITHUB_ENV`,
which the runner folds into the job's global environment — overwriting any
prior value. This meant the obvious way to opt out of metrics was broken.

Guard the single `run()` export so it only fires when the caller actually
passes the input. When `disable-metrics` is unset (the new default of `""`),
the action leaves `FLOX_DISABLE_METRICS` untouched — at whatever value the
caller already set, or absent, in which case the flox CLI applies its own
default (disabled by its `#[serde(default)]` bool).

`action.yml` default changed from `"false"` to `""` and the description
expanded to explain the new semantics. `README.md` inputs table updated to
match. `dist/index.js` rebuilt to match.

Tests cover both branches of the `run()` guard: an unset input leaves
`FLOX_DISABLE_METRICS` untouched (the regression), and an explicit value is
still exported. 64 tests pass, statement/line coverage at 100%.

Refs: ECO-104
Forge-Agent: implementation-worker (03fbd38a)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@dcarley
dcarley force-pushed the fix/eco-104-disable-metrics-default branch from 8cd1dfb to 8bbc0f0 Compare June 24, 2026 14:31
@dcarley
dcarley merged commit a4a37cd into main Jun 24, 2026
20 checks passed
@dcarley
dcarley deleted the fix/eco-104-disable-metrics-default branch June 24, 2026 14:33
@dcarley

dcarley commented Jun 24, 2026

Copy link
Copy Markdown
Contributor Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

team-developer-support Work related to the developer support team

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants