fix(manifest): auto-manifest reads the Conda file it actually detected

[Martin Torp (mtorp)]

The bug

--auto-manifest detects a Conda project by looking for either environment.yml or environment.yaml, but detectManifestActions() only returned conda: true and threw the filename away. generateAutoManifest() then read environment.yml unconditionally.

So on a repo whose Conda file is environment.yaml, every run does this:

Detected an environment.yml file, running default Conda generator...
Manifest Generation Failed: The file was not found at <repo>/environment.yml

The scan still uploads, the CLI still exits 1. The customer gets a completed scan and a failed CI job on every run, and the packages in the file's pip: block never reach the scan because the conversion that produces them is the step that failed.

The known workaround is a socket.json with defaults.manifest.conda.infile pointing at the real filename, which works because that override is the one path that does not go through the hardcoded default.

The fix

Detection now reports which file it found (GeneratableManifests.condaFile) and the generator reads that one. A socket.json infile still wins when it is set.

Two more bugs in the same code path

The generated requirements.txt landed in the wrong directory. It was written relative to process.cwd() rather than the target dir, so socket manifest auto <dir> and socket scan create <org> <dir> dropped it outside the tree being scanned and the scan never picked it up. The --out flag already documents itself as relative to cwd, so this just makes the code match. Invisible when you run from the repo root, which is what CI does.

Conda was the one auto-manifest ecosystem with no fail-closed check. Gradle, Maven and sbt abort the run when their generator fails (#1392); Conda just set exit 1 and carried on. That is what produces the "completed scan + failed CI job" pair, and the scan that uploads is missing the pip: packages. Conda now calls abortManifestRunIfFailed like the others.

That last one is a deliberate behavior change and the one thing worth a second opinion. Before: scan uploads, exit 1. After: the run stops before upload. It matches the policy the other ecosystems already follow, on the grounds that a partial SBOM silently under-reports dependencies. Happy to drop it if the team would rather warn and continue.

socket manifest conda on its own also falls back to .yaml now, so the two commands agree on what counts as a Conda file.

Verification

Repro, on a directory containing only an environment.yaml with a pip: block:

• Before: Manifest Generation Failed: The file was not found at .../environment.yml, exit 1.
• After: converts, writes requirements.txt into the target dir, exits 0.

Also checked: .yml unchanged, socket.json infile still wins over the detected file, and an unreadable Conda file now aborts the run instead of uploading a partial scan.

pnpm run check and pnpm run check:tsc pass. src/commands/manifest 503 passed, src/commands/scan 274 passed. New unit tests cover both detection and the generator branch.

Release

No hand-written version bump. The changelog entries go under ## [Unreleased] for the publish workflow to promote.

[Jeppe Fredsgaard Blaabjerg (jfblaa)]

[agent] Superseded by #1562 — same commit rebased onto v1.x after the 1.1.179 release, plus end-to-end verification. Your hand-written ## [1.1.179] changelog heading collided with the real one the release workflow has since written, so it was dropped in the rebase. Closing this in favour of #1562.