re-instating conditional use of codeclimate and deepsource tools in CI

[coderabbitai]

Summary:

In PR #127, we observed that the conditional checks for running cc-test-reporter and deepsource tools in the GitHub Actions CI workflow were removed. This change causes these tools to execute in all CI environments, including those where they may not be available, leading to potential job failures.

During the discussion in this comment, it was acknowledged that this needs to be corrected so that these tools only run on Linux or Darwin (macOS) environments. The implementation for the correct conditional checks exists in the template repository reactive-firewall/python-repo.

Plan:

1. Review the previous implementation of OS-specific conditional checks in the reactive-firewall/python-repo template repository.

2. Reintroduce conditional checks in the CI workflow to ensure cc-test-reporter and deepsource run only on Linux or Darwin (macOS) environments.

3. Update the CI workflow YAML files accordingly, adding appropriate if conditions to the steps involving these tools.

4. Verify that the tools are properly installed and available on the supported environments within the CI jobs.

5. Test the updated workflow across different operating systems to confirm that the tools run where expected and are skipped elsewhere.

6. Apply the updated CI configuration to relevant repositories using the template, ensuring consistency.

Requested by: @reactive-firewall

Backlinks:

• PR: reactive-firewall/multicast#127
• Comment: #discussion_r1774292002

Mappings:

• https://github.com/reactive-firewall/multicast/security/code-scanning/262
• https://github.com/reactive-firewall/multicast/security/code-scanning/263

[reactive-firewall]

🤔 Regarding part 1 of the suggested plan, the focus would be on how the reactive-firewall/python-repo template repository implemented a tool for part of the code-climate steps

[reactive-firewall]

@coderabbitai FYI: see the implementation of fetch-cc-tool and its counter part `` in this gist which can be git-submoduled as already done in my other repository, see PR reactive-firewall/python-repo#82

This unblocks this GHI, however I am considering if we want the whole makefile include integration, just cloning the submodule and directly running the scripts in GHA workflows might be a better compromise in this project's specific case. Please explore this idea a bit more with me.

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# First, let's examine the gist content
curl -s https://gist.githubusercontent.com/reactive-firewall/c718380a1747d43dda1519167fc50ac0/raw

# Let's also check if there are any existing workflow files in the current project that might be relevant
find .github/workflows -type f -name "*.yml" | xargs head -n 5

# And see if there's any existing makefile integration
find . -name "Makefile" -o -name "*.mk" | xargs grep -l "include" || echo "No Makefile includes found"

Length of output: 3376

---

🏁 Script executed:

#!/bin/bash
# Let's try to get the specific files from the gist 
curl -s https://gist.githubusercontent.com/reactive-firewall/c718380a1747d43dda1519167fc50ac0/raw/fetch-cc-tool
echo "-------------------"
curl -s https://gist.githubusercontent.com/reactive-firewall/c718380a1747d43dda1519167fc50ac0/raw/cc-reporter-makefile.mk

# Let's examine the Makefile includes
grep -A 5 "include" ./Makefile

# Let's look at how GH Actions are currently set up that might be related to code climate
find .github/workflows -type f -name "*.yml" -exec grep -l "code-climate\|codeclimate\|cc-reporter\|cc_reporter" {} \; | xargs cat || echo "No Code Climate workflows found"

# Let's check if there's any existing implementation of code climate tools in the repository
find . -type f -name "*cc*" -o -name "*code-climate*" | grep -v ".git" || echo "No Code Climate files found"

Length of output: 22283

---

🏁 Script executed:

#!/bin/bash
# Let's try to explore the gist content differently
curl -s https://gist.github.com/reactive-firewall/c718380a1747d43dda1519167fc50ac0

# Let's look at the existing cc tool implementation in the project
cat ./tests/check_cc_lines || echo "File doesn't exist"

# Let's also look at the repository mentioned in the PR reference (python-repo)
# First, let's get the content of the fetch-cc-tool in python-repo
curl -s https://raw.githubusercontent.com/reactive-firewall/python-repo/master/tests/fetch_cc-test-reporter || echo "File doesn't exist"

# Let's see if we can get any Makefile integration related to cc-reporter from python-repo
curl -s https://raw.githubusercontent.com/reactive-firewall/python-repo/master/Makefile | grep -A 10 "code-climate\|cc-" || echo "No Makefile integration found"

# Let's check if PR #82 in python-repo is related to git submodules
curl -s https://api.github.com/repos/reactive-firewall/python-repo/pulls/82 | grep -i "title\|body" | head -10

Length of output: 73871

---

🏁 Script executed:

#!/bin/bash
# Let's try to examine the individual files from the gist
curl -s https://gist.githubusercontent.com/reactive-firewall/c718380a1747d43dda1519167fc50ac0/raw/LICENSE.md
echo "=====FILES IN THE GIST====="
curl -s https://api.github.com/gists/c718380a1747d43dda1519167fc50ac0 | grep -o "\"filename\": \"[^\"]*\"" || echo "No filenames found"

# Look at the contents of python-repo PR #82 to understand its implementation
curl -s https://api.github.com/repos/reactive-firewall/python-repo/pulls/82 | grep -A 2 "title\|body"

# Let's also check our issue #130 to understand what we're trying to solve
curl -s https://api.github.com/repos/reactive-firewall/multicast/issues/130 | grep -A 5 "title\|body"

# Let's see if there's any existing implementation of the check_cc_lines script
cat ./tests/check_cc_lines 2>/dev/null || echo "File doesn't exist or can't be read"

# And check for existing GHA workflows or makefiles that may need updating
grep -r "code-climate" .github/workflows/ --include="*.yml" | head -20

Length of output: 14179

---

@reactive-firewall Thank you for sharing the gist with the code-climate tools implementation! I've taken a look at both the gist contents and the current implementation in the multicast repository.

The gist contains four files:

• LICENSE
• fetch-test-reporter
• purge-test-reporter
• tools-fetch-test-reporter.make

These tools help integrate code-climate reporting into your CI workflows, and the question is whether to:

1. Use the Makefile include integration (similar to python-repo PR [PATCH] Minor improvements to 'check_legacy_setup_coverage' #82)
2. Clone the submodule and directly run scripts in GHA workflows

Let's explore both approaches:

Option 1: Makefile Integration

This would involve adding the gist as a submodule and using the tools-fetch-test-reporter.make file with include statements in your Makefile.

Pros:

• Standardized approach consistent with your python-repo
• Centralized management of tool logic
• Reusable across projects

Cons:

• More complex setup
• Additional Makefile dependency

Option 2: Direct Script Execution in GHA

This would involve cloning the submodule and directly invoking the scripts in your workflows.

Pros:

• Simpler implementation
• More direct control in the workflow
• Fewer dependencies between systems
• Easier to debug

Cons:

• Less standardized
• Might require more workflow-specific code

Recommendation

Based on your learnings and preferences (particularly for improving organization within single files rather than splitting), and considering this project's specific needs, I'd recommend Option 2 - directly running the scripts in GHA workflows.

This approach would:

1. Keep your workflow files self-contained
2. Still allow reuse of the tool scripts from the gist
3. Provide direct control over conditional execution based on OS
4. Simplify debugging and maintenance

The implementation would involve adding the gist as a submodule, then referencing the scripts directly in your workflow with appropriate conditionals for Linux/Darwin environments.

Would you like me to outline a more detailed implementation plan for either approach?

---

🧠 Learnings used

Learnt from: reactive-firewall
PR: reactive-firewall/ymmv#9
File: payload/bin/lsmap:17-27
Timestamp: 2024-11-07T04:15:11.692Z
Learning: Reactive-firewall prefers scripts to support both BSD and GNU versions of commands, with a slight preference for BSD.

---

Learnt from: reactive-firewall
PR: reactive-firewall/multicast#115
File: multicast/hear.py:180-180
Timestamp: 2024-10-08T21:59:30.537Z
Learning: Reactive-firewall prefers to re-use already loaded modules to keep memory overhead low when possible.

---

Learnt from: reactive-firewall
PR: reactive-firewall/multicast#115
File: multicast/hear.py:180-180
Timestamp: 2024-09-19T03:43:24.037Z
Learning: Reactive-firewall prefers to re-use already loaded modules to keep memory overhead low when possible.

---

Learnt from: reactive-firewall
PR: reactive-firewall/multicast#0
File: :0-0
Timestamp: 2025-03-31T21:08:36.149Z
Learning: In the multicast project, when refactoring shell scripts, prefer improving organization within a single file over splitting into multiple files, unless the benefits of modularity clearly outweigh the added complexity in security, permissions, and debugging.

---

Learnt from: reactive-firewall
PR: reactive-firewall/multicast#0
File: :0-0
Timestamp: 2025-03-31T21:08:14.204Z
Learning: For future scripts, reactive-firewall prefers to use only POSIX built-ins (like `printf` instead of `echo`) to align with CEP-8 conventions.

---

Learnt from: reactive-firewall
PR: reactive-firewall/multicast#0
File: :0-0
Timestamp: 2025-03-31T21:08:04.263Z
Learning: Reactive-firewall prefers to specify the full raw URL when fetching files from gists to ensure correct retrieval of content, particularly when the file is in markdown format.

---

Learnt from: reactive-firewall
PR: reactive-firewall/multicast#0
File: :0-0
Timestamp: 2025-03-31T21:08:27.939Z
Learning: For future scripts, reactive-firewall prefers to keep the shebang line with an extra space (e.g., `#! /bin/bash`) as per project style.

---

Learnt from: reactive-firewall
PR: reactive-firewall/multicast#0
File: :0-0
Timestamp: 2025-03-31T21:08:27.939Z
Learning: For future reviews, remember that when drafting or updating CEP (Convention Enhancement Proposal) documents, it's important to adhere to the project's standard format and include all relevant sections such as Motivation, Detailed Explanation, Implementation Guidelines, Impact, and References.

---

Learnt from: reactive-firewall
PR: reactive-firewall/multicast#184
File: LICENSE.md:36-43
Timestamp: 2025-03-31T21:08:22.764Z
Learning: Reactive-firewall prefers that I verify URLs before suggesting changes, and avoid raising hypothetical issues without verification.

---

Learnt from: reactive-firewall
PR: reactive-firewall/multicast#235
File: .github/workflows/makefile-lint.yml:41-52
Timestamp: 2025-03-31T21:08:36.149Z
Learning: Reactive-firewall prefers to suppress errors in `apt-get install` commands when individual checks of the installed packages are performed afterwards, to allow for more granular error handling.

---

Learnt from: reactive-firewall
PR: reactive-firewall/multicast#0
File: :0-0
Timestamp: 2025-03-31T21:08:14.204Z
Learning: In the multicast project's shell scripts, prefer organizing code into logical sections with clear comments (e.g., "=== Environment Setup ===") to maintain readability and maintainability while keeping related functions together.

---

Learnt from: reactive-firewall
PR: reactive-firewall/multicast#0
File: :0-0
Timestamp: 2025-03-31T21:08:04.263Z
Learning: Reactive-firewall prefers that overviews and release notes include a mention of how strategies learned from the project have been applied to improve the final result.

---

Learnt from: reactive-firewall
PR: reactive-firewall/multicast#184
File: tests/check_pip:259-265
Timestamp: 2025-03-31T21:08:14.204Z
Learning: Reactive-firewall prefers that code changes adhere to SOLID design principles, specifically avoiding unnecessary complexity (AHA principle), maintaining the Single Responsibility Principle, and ensuring complex work is done on separate development branches (Open/Closed Principle).

[reactive-firewall]

@coderabbitai, I approve of option 2; indeed, let us proceed to outline a more detailed implementation of option 2, namely:

• we need to identify where to best insert the calls to fetch-test-reporter and purge-test-reporter (to cleanup after)
• we should leverage our recent success with GHA in v2.0.x Chore - Improve CI by refactoring workaround upgrade action #210 and implement the custom workflow logic as callable GHA, or perhaps even a small set of callable GHAs if simpler 🤷🏻
• we should ensure the new integration remains optional (eg. skip, not fail on missing) but also opportunistic (eg. best-effort attempts before giving up)

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

Tip

The multi-step agents feature is in experimental mode.

A summary of the edits CodeRabbit can apply:

• We will create a new GitHub Actions workflow file “.github/workflows/fetch-test-reporter.yml” that implements Option 2 – directly running the test reporter scripts as part of the CI workflow. This workflow will:

  1. Check out the repository with submodules enabled.
  2. Conditionally invoke the “fetch-test-reporter” script (located at “./tests/fetch-test-reporter”) if it exists, using a shell check so that the integration is optional and only runs if present.
  3. Always run a cleanup step (using “if: always()”) that conditionally invokes the “purge-test-reporter” script (located at “./tests/purge-test-reporter”) to clean up after execution.

• We will create a new GitHub Actions workflow file at .github/workflows/purge-test-reporter.yml that implements an optional cleanup step for the test reporter integration. This workflow leverages our recent success with GHA (per v2.0.x Chore - Improve CI by refactoring workaround upgrade action #210) by using workflow_call so it can be invoked by other workflows. It checks out the repository with submodules enabled, verifies if the purge-test-reporter script exists and is executable, and then runs it. The step is configured with continue-on-error to avoid failing the overall workflow if the cleanup step is skipped.

A summary of the context that CodeRabbit is considering across the codebase:

• This workflow follows Option 2 by directly executing the test reporter scripts from the repository submodule when available. It leverages the “workflow_call” trigger for reusability, ensures that submodules are checked out, conditionally runs the fetch-test-reporter script, and always attempts cleanup with the purge-test-reporter script. This implementation is optional and best-effort, which aligns with our recent successful GHA integration (v2.0.x Chore - Improve CI by refactoring workaround upgrade action #210).

• This workflow is intended to implement an optional purge cleanup step by calling the external "purge-test-reporter" script from a git submodule. We are using the workflow_call trigger (similar to our recent GHA implementation in v2.0.x Chore - Improve CI by refactoring workaround upgrade action #210) so that other workflows can invoke it as needed. The design ensures that any issues with the purge step do not cause the entire workflow to fail, in line with our best-effort strategy.

• Generated copyable edits - (🔄 Check again to refresh)

[coderabbitai]

Here are the copyable edits based on the planned changes:

Copyable Edits

.github/workflows/fetch-test-reporter.yml

name: Fetch Test Reporter

on:
  workflow_call:

jobs:
  fetch-test-reporter:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository and submodules
        uses: actions/checkout@v3
        with:
          submodules: true
      - name: Run fetch-test-reporter if available
        run: |
          if [ -f ./tests/fetch-test-reporter ]; then
            chmod +x ./tests/fetch-test-reporter
            ./tests/fetch-test-reporter || echo "fetch-test-reporter script failed, continuing..."
          else
            echo "Optional fetch-test-reporter not found; skipping."
          fi
      - name: Cleanup - Run purge-test-reporter if available
        if: always()
        run: |
          if [ -f ./tests/purge-test-reporter ]; then
            chmod +x ./tests/purge-test-reporter
            ./tests/purge-test-reporter || echo "purge-test-reporter script failed, but proceeding with cleanup."
          else
            echo "Optional purge-test-reporter not found; skipping cleanup."
          fi

.github/workflows/purge-test-reporter.yml

# This reusable GitHub Actions workflow performs a cleanup step by executing the purge-test-reporter script.
# The cleanup step is optional and can be disabled by setting the "enabled" input to false when calling this workflow.
on:
  workflow_call:
    inputs:
      enabled:
        description: 'Flag to enable or disable the purge step. Set to false to skip cleanup.'
        required: false
        default: true
        type: boolean

jobs:
  purge_test_reporter:
    runs-on: ubuntu-latest
    steps:
      # Checkout the repository including submodules (ensuring the external submodule with the purge script is available)
      - name: Checkout code with submodules
        uses: actions/checkout@v3
        with:
          submodules: true

      # Conditionally run the purge-test-reporter script if "enabled" is true.
      # The continue-on-error flag is set to allow the workflow to succeed even if the cleanup step fails.
      - name: Run Purge Test Reporter
        if: ${{ inputs.enabled }}
        continue-on-error: true
        run: |
          echo "Starting purge test reporter step..."
          # Check if the purge-test-reporter script exists and is executable
          if [ -x ./tools/purge-test-reporter ]; then
            echo "Found purge-test-reporter script. Executing..."
            ./tools/purge-test-reporter
          else
            echo "Purge-test-reporter script not found or not executable. Skipping cleanup step."
          fi

Apply Changes

• ✅ Create PR with these edits

• 📌 Create commit in current branch

[reactive-firewall]

@coderabbitai, let's consider reusable actions instead of just workflows; that way existing workflows like .github/workflows/Tests.yml and .github/workflows/mats.yml can just integrate the optional script with a uses: .github/actions/fetch-test-reporter and similar for purge (after testing), the only complicated part is ensuring the correct working path for the fetch script (which should be the git top-directory of the super project)

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

Caution

CodeRabbit has failed to create the PR to execute your edits.

[reactive-firewall]

🤔 I'm thinking more like:

sequenceDiagram
    participant CI/CD-GHA as Existing GitHub Action
    participant Fetch-Action
    participant Purge-Action
    participant New-CI-GHA as New Reporting GitHub Action
    participant submodule
    participant fetch-script
    participant purge-script

    CI/CD-GHA-->>submodule: checkout
    submodule->>CI/CD-GHA: successful
    CI/CD-GHA-->>Fetch-Action: useing
    Fetch-Action-->>submodule: status of fetch script?
    submodule->>Fetch-Action: available
    Fetch-Action-->>fetch-script: invoke
    fetch-script->>Fetch-Action: fetches tools
    Fetch-Action->>CI/CD-GHA: Fetched
    CI/CD-GHA-->>CI/CD-GHA: Run tests to generate coverage data.
    CI/CD-GHA-->>New-CI-GHA: useing
    New-CI-GHA-->>New-CI-GHA: use fetched tools to upload coverage data
    New-CI-GHA->>CI/CD-GHA: Uploaded
    CI/CD-GHA-->>Purge-Action: useing
    Purge-Action-->>submodule: status of purge script?
    submodule->>Purge-Action: available
    Purge-Action-->>purge-script: invoke
    purge-script->>Purge-Action: purges tools
    Purge-Action->>CI/CD-GHA: purged

Loading

Key Tasks:

• Integrate submodule:

    - uses: actions/checkout@v4
      with:
        submodules: true
        persist-credentials: false

• plan and create .github/actions/fetch-test-reporter/action.yml
• plan and create .github/actions/upload-test-reports/action.yml
• plan and create .github/actions/purge-test-reporter/action.yml
• Integrate new actions into .github/workflows/Tests.yml's COVERAGE and INTEGRATION jobs