Fix macOS CI: replace GNU-only grep -P with POSIX-compatible awk/grep -E in Stage 3

[Copilot]

Description

macOS runners use BSD grep, which does not support -P (Perl-compatible regex). The grep -oP usages in the Stage 3 macOS coverage gate in pr.yaml fail with invalid option, breaking the coverage threshold enforcement step even when coverage is 100%. Stage 1 (Linux) and Stage 2 (Windows) were not affected — Linux uses GNU grep (which supports -P) and Windows uses PowerShell.

Changes — .github/workflows/pr.yaml

• Stage 3 macOS coverage gate (lines 706–707) — root cause fix: replaced grep -oP '^[^ ]+' and grep -oP '[0-9]+(?=%)' with POSIX-compatible alternatives that work on BSD grep:
  • Module extraction: awk '{print $1}'
  • Percentage extraction: grep -oE '[0-9]+%' | tail -1 | tr -d '%'

Stage 1 and Stage 2 are unchanged and continue to use the original grep -oP forms, which work correctly on their respective ubuntu-latest and windows-latest runners.

Type of change

• Bug fix

How Has This Been Tested?

• Verified replacement logic locally: grep -oE + tr -d '%' produces identical output to the Perl lookahead variant on both GNU and BSD toolchains

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

Screenshots (if applicable)

Additional context

No changes to test projects, coverage configuration, or any source code — only the Stage 3 macOS shell parser logic in the workflow was modified.

Original prompt

Stage 3 (macOS) for GitHub Actions CI fails on the coverage threshold enforcement step because the build script uses GNU-specific 'grep -P' (Perl regex support) and '-oP', which are not supported on macOS's BSD grep. As a result, parsing CoverageReport/Summary.txt fails with an invalid option error, and the pipeline exits with error code 2 even though coverage is 100%.

Solution:

• Replace all uses of 'grep -oP' and 'grep -P' in Bash steps with POSIX-compatible alternatives (such as 'awk' for extracting modules and percentage values).
• Ensure that coverage threshold logic works identically across Linux and macOS runners (GNU vs BSD tools differences).
• Validate by ensuring Stage 3 pipeline passes and the correct modules/percent checks are present in workflow logs and summary.

No changes needed to test or coverage configuration — only Bash parser logic.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: check this repo

Assistant: Here's a summary of the repository Chris-Wolfgang/ETL-Abstractions:

• Description: Interfaces and base classes for creating ETLs
• Repo URL: https://github.com/Chris-Wolfgang/ETL-Abstractions
• Public / MIT Licensed
• Primary language: C# (70.6%), with some PowerShell (29.4%)
• Topics: etl-framework
• Default branch: main
• Open issues: 7
• Has Actions, Projects, Wiki, and Pages enabled
• Active: Last pushed 2 hours ago
• Not archived, not a fork

If you need any details on its structure, current issues, CI configuration, or run into build/test errors, let me know and I can retrieve or investigate more specific information for you!

User: check that repo to determine why I am getting the no tests found error

Assistant: Your test project and files do exist in the repository—specifically, at tests/Wolfgang.Etl.Abstractions.Tests.Unit/Wolfgang.Etl.Abstractions.Tests.Unit.csproj, and there are many Fact unit tests present.

However, the recurring CI message "❌ No test projects found in ./tests directory!" points to a CI/CD script issue—not missing test files.

Root Cause Likely:

• Your workflow probably uses a Bash step with something like:

  mapfile -d '' -t test_projects < <(find ./tests -type f \( -name "*.csproj" -o -name "*.vbproj" -o -name "*.fsproj" \) -print0)
  if [ ${#test_projects[@]} -eq 0 ]; then
    echo "❌ No test projects found in ./tests directory!"
    exit 1
  fi

• If this step fails to find the test project (even though it exists), there are typically three reasons:
  1. Not running with Bash – mapfile requires Bash. If the step defaults to sh, it will always fail.
  2. Incorrect working directory – The workflow step is not running from the repo root (where ./tests exists).
  3. Checkout step problem – The repo wasn’t actually checked out, or is missing files due to shallow or partial clone.

---

Recommendations

1. Make Sure You're Using Bash in Your Workflow Step

In your .github/workflows/ YAML:

- name: Discover test projects
  run: |
    mapfile -d '' -t test_projects < <(find ./tests -type f \( -name "*.csproj" -o -name "*.vbproj" -o -name "*.fsproj" \) -print0)
    if [ ${#test_projects[@]} -eq 0 ]; then
      echo "❌ No test projects found in ./tests directory!"
      exit 1
    fi
  shell: bash

Note: That last line is critical: shell: bash.

2. Confirm Paths and Working Directory

Make sure this step is not running in a subfolder (like src/, examples/, etc.). It should run from the root where the tests folder exists.

3. Ensure Proper Repository Checkout

Earlier in your workflow, add:

- uses: actions/checkout@v4

---

Summary Table

Item	Is it in your repo?	Fix needed?
Test project	Yes	No
Bash shell	Maybe (check YAML)	Yes if missing
Correct path	Yes	Only run at root
Repo checkout	Undetermined	Add/verify step

---

You can view and modify your workflow file to apply these fixes.
Want the exact lines to add or update for your workflow YAML? Let me know!

See full code search for 'test' in this repository. (for deeper analysis)

User: check the pr.yaml file for isses and make sure it is looking on the correct place

Assistant: Here’s what the relevant part of your .github/workflows/pr.yaml does, based on the search:

1. Test project discovery:

   mapfile -d '' -t test_projects < <(find ./tests -type f \( -name "*.csproj" -o -name "*.vbproj" -o -name "*.fsproj" \) -print0)
   if [ ${#test_projects[@]} -eq 0 ]; then
     echo "❌ No test projects found in ./tests directory!"
     exit 1
   fi

2. **I...

This pull request was created from Copilot chat.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[Chris-Wolfgang]

@copilot since it was working on step 1 and 2 do we just need to update step 3 on the mac?

[Copilot]

@copilot since it was working on step 1 and 2 do we just need to update step 3 on the mac?

You're correct — the actual failure was only in Stage 3 (macOS). Lines 706–707 were the ones running on macos-latest with BSD grep, which doesn't support -P.

Lines 150, 201, and 266–267 are in Stage 1 (ubuntu-latest) which uses GNU grep that already handled -P fine. I updated those too for consistency and portability, but they weren't the root cause of the failure. The changes are safe and don't affect the Linux or Windows stages.

[Chris-Wolfgang]

@copilot Can you put back the changes for step 1 and 2 and just leave 3

[Copilot]

@copilot Can you put back the changes for step 1 and 2 and just leave 3

Done. Reverted Stage 1/2 back to the original grep -oP — only the Stage 3 macOS block (lines 706–707) retains the POSIX-compatible fix. Commit 8aa74cf.