Add exception handling for non-Dockerfile formats

[Julian (jpinz)]

This pull request improves the Dockerfile component detector's handling of files that are named like Dockerfiles but contain other formats. Parse failures are now treated as expected non-Dockerfile input and logged as warnings, while other processing failures remain errors.

The detector also skips files under node_modules, where packages may include Dockerfile language definitions that are not build instructions. Tests cover JavaScript content in dockerfile.mjs and dockerfile.d.mts, as well as a Dockerfile-like file under node_modules, ensuring these files do not produce false positives.

[Copilot]

Copilot review overview

🟡 Changes recommended

Tests do not verify the new logging behavior, and Sprache lacks a direct package reference.

Review effort: Balanced
Findings: 2

Open (2)

• Declare Sprache as an explicit centrally versioned dependency · New
• Assert warning logging for ParseException test cases · New

What changed in this PR

Improves Dockerfile detector handling of non-Dockerfile content.

Changes:

• Treats parser failures as warnings.
• Adds tests for Shiki JavaScript definition files.

File	Description
DockerfileComponentDetector.cs	Adds specialized parse-error handling.
DockerfileComponentDetectorTests.cs	Adds non-Dockerfile test cases.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

👋 Hi! It looks like you modified some files in the Detectors folder.
You may need to bump the detector versions if any of the following scenarios apply:

• The detector detects more or fewer components than before
• The detector generates different parent/child graph relationships than before
• The detector generates different devDependencies values than before

If none of the above scenarios apply, feel free to ignore this comment 🙂

[Copilot]

Copilot review overview

🟡 Changes recommended

Dependency declaration, logging verification, and the undocumented blanket node_modules exclusion need resolution.

Review effort: Balanced
Findings: 3 · 1

Open (4)

• Avoid excluding valid Dockerfiles under node_modules · New
• Assert warning logging for ParseException test cases
• Declare Sprache as an explicit centrally versioned dependency
• Test warning logging for Dockerfile parse failures · New

[Ryan Brandenburg (ryanbrandenburg)]

One nitpick that the bot had already made, but don't block on if it's going to be annoying.

[Copilot]

Copilot review overview

🔵 Needs a closer look

The output-changing exclusion requires incrementing the detector version.

Review effort: Balanced
Findings: None

Resolved since last review (4)

• Avoid excluding valid Dockerfiles under node_modules
• Assert warning logging for ParseException test cases
• Declare Sprache as an explicit centrally versioned dependency
• Test warning logging for Dockerfile parse failures

Previously missed (1)

In code that hasn't changed since last review

Increment detector version when excluding node_modules components

src/​Microsoft.ComponentDetection.Detectors/​dockerfile/​DockerfileComponentDetector.cs:47

Skipping every matching file under node_modules intentionally removes components that version 1 previously reported, but the detector version is unchanged. The repository requires detector versions to be incremented for breaking output changes (docs/creating-a-new-detector.md:178), and verification uses version increases to identify intentional detector changes (ComponentDetectionIntegrationTests.cs:240-265). Increment this detector to version 2 with the new exclusion.

[Copilot]

Copilot review overview

🔵 Needs a closer look

The detector version must be incremented for the breaking output change.

Review effort: Balanced
Findings: None

Previously missed (1)

In code that hasn't changed since last review

Bump detector version for breaking output change

src/​Microsoft.ComponentDetection.Detectors/​dockerfile/​DockerfileComponentDetector.cs:45

Skipping an entire path class can remove DockerReference components that version 1 previously reported, so this is a breaking detector-output change. The repository's detector guidance requires incrementing Version for breaking changes (docs/creating-a-new-detector.md:176-179); bump this detector to version 2 so consumers can identify the changed results.