feat(web): allow dotnet pipeline steps to skip missing projects

[PrzemyslawKlys]

Summary

• add skipIfProjectMissing support for dotnet-build and dotnet-publish pipeline tasks
• support aliases skipIfMissingProject and skip-if-project-missing
• return successful skip messages instead of hard-failing when project paths are absent
• document the option in pipeline docs and JSON schema
• add pipeline runner tests for both dotnet tasks

Why

• improves worktree-only and partial-checkout workflows
• keeps CI pipelines predictable across HtmlForgeX, IntelligenceX, and CodeGlyphX when optional project paths are unavailable in a given checkout

Validation

• dotnet test .\PowerForge.Tests\PowerForge.Tests.csproj -c Release --filter FullyQualifiedName~WebPipelineRunnerDotNetStepTests
• dotnet test .\PSPublishModule.sln -c Release

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

[claude]

Pull Request Review: feat(web): allow dotnet pipeline steps to skip missing projects

Summary

This PR adds skipIfProjectMissing functionality to dotnet-build and dotnet-publish pipeline tasks, allowing pipelines to gracefully skip these steps when project files are unavailable. This is useful for worktree-only and partial-checkout workflows.

Code Quality & Best Practices

Strengths ✅

1. Clear Implementation: The TrySkipDotNetStepForMissingProject helper method follows the single-responsibility principle and is well-structured
2. Consistent Pattern: The implementation pattern matches existing codebase conventions seen in other pipeline tasks
3. Good Alias Support: Supporting multiple naming conventions (skipIfProjectMissing, skipIfMissingProject, skip-if-project-missing) provides flexibility
4. Complete Documentation: JSON schema and markdown documentation are properly updated
5. Test Coverage: Dedicated test file with appropriate test cases for both dotnet-build and dotnet-publish scenarios

Areas for Consideration

1. Path Resolution Timing (Minor Issue)

Location: PowerForge.Web.Cli/WebPipelineRunner.Tasks.DoctorAndDotnet.cs:308, 340

The ResolvePath is called before the skip check. This means the path is resolved relative to baseDir before checking if it exists:

var project = ResolvePath(baseDir, GetString(step, "project") ?? ...);
// ...
if (TrySkipDotNetStepForMissingProject(project, skipIfProjectMissing, stepResult, "dotnet build"))
    return;

This is actually correct behavior since you want to check the resolved absolute path, but it could be misleading if users expect to check the raw input path. The current implementation is appropriate.

2. Directory vs File Check (Potential Edge Case)

Location: PowerForge.Web.Cli/WebPipelineRunner.Tasks.DoctorAndDotnet.cs:401

if (File.Exists(project) || Directory.Exists(project))
    return false;

This checks both files and directories. This is good for supporting solution files (.sln) which are files, and project directories. However, consider:

• What if a symbolic link to a missing target exists? On some systems, File.Exists may return false for a broken symlink
• This is likely acceptable for the use case, but worth documenting if this becomes an issue

3. Test File Namespace (Minor Inconsistency)

Location: PowerForge.Tests/WebPipelineRunnerDotNetStepTests.cs:6

The test class doesn't have a namespace declaration, while other test files in the same directory (e.g., WebPipelineRunnerApiDocsPreflightTests.cs) also lack namespaces. This appears to be a project convention, so it's consistent.

4. Error Message Clarity

Location: PowerForge.Web.Cli/WebPipelineRunner.Tasks.DoctorAndDotnet.cs:405

stepResult.Message = $"{taskLabel} skipped: project path not found '{project}'";

The message shows the resolved path. For debugging, users might want to see the original input path as well. However, showing the resolved path is more useful for understanding what was actually checked.

Performance Considerations

✅ No concerns. The skip check is an early-return pattern that avoids expensive operations:

• File.Exists and Directory.Exists are lightweight syscalls
• The check happens before any dotnet CLI invocations
• No additional I/O or processing overhead

Security Considerations

Path Traversal Safety ✅

The implementation correctly uses the existing ResolvePath helper which:

1. Combines paths using Path.Combine (safe against traversal)
2. Respects absolute paths when provided
3. Follows the same pattern used throughout the codebase

No New Security Risks

• The feature makes pipelines more forgiving, not more permissive
• No execution of user-supplied code or commands
• No network operations introduced
• File existence checks are read-only operations

Test Coverage

Excellent Coverage ✅

The test file includes:

1. Happy path test for dotnet-build: Verifies skip behavior works correctly
2. Happy path test for dotnet-publish: Verifies skip behavior works correctly
3. Cleanup handling: Proper TryDeleteDirectory with exception handling
4. Test isolation: Uses temp directories with GUIDs to avoid conflicts

Potential Additional Tests (Optional Enhancements)

Consider adding tests for:

1. Default behavior: When skipIfProjectMissing is false or not set, ensure it still throws/fails as expected
2. Edge case: Project path exists but is an empty directory (should proceed, not skip)
3. Alias verification: Test that all three alias forms (skipIfProjectMissing, skipIfMissingProject, skip-if-project-missing) work correctly
4. Integration: End-to-end test with an actual small project to verify normal operation isn't affected

However, the current test coverage is solid for the core functionality.

Documentation

Schema Updates ✅

The JSON schema properly documents:

• All three property aliases with descriptions
• Clear description of the feature's purpose
• Proper boolean type definition

Markdown Documentation ✅

The documentation in Docs/PowerForge.Web.Pipeline.md:

• Shows practical examples with the new property
• Includes notes explaining the feature and its use case
• Lists all supported alias forms

Validation Results

The PR description mentions running:

dotnet test .\PowerForge.Tests\PowerForge.Tests.csproj -c Release --filter FullyQualifiedName~WebPipelineRunnerDotNetStepTests

✅ This command should successfully run both new tests (though I couldn't execute it due to permissions in the review environment).

Recommendations

Must Fix

None - the implementation is solid.

Should Consider (Low Priority)

1. Add negative test case: Test that when skipIfProjectMissing: false or is omitted, the step properly fails with a missing project
2. Test alias variants: Add a quick test verifying all three naming conventions work

Nice to Have

1. Document the resolved path behavior: Add a comment in the code or docs noting that the check uses the resolved absolute path
2. Consider logging: For debugging, you might want to log (if a logger is available) when a step is skipped

Overall Assessment

✅ APPROVED - This is a well-implemented feature that:

• Solves a real problem for worktree and partial-checkout workflows
• Follows existing code patterns and conventions
• Has appropriate test coverage
• Includes complete documentation
• Introduces no security or performance concerns
• Has clean, readable code

The implementation is production-ready. The optional enhancements suggested above would make it even more robust but are not blockers for merging.

---

Reviewed by: Claude Code (Sonnet 4.5)
Review Date: 2026-02-13