Improve and Generalize `fetch_cc-test-reporter` tool as gist submodule

[reactive-firewall]

Improve and Generalize fetch-test-reporter tool

Improvements

CEP-8 Compliance

• change lines around 158 to code 77 for permission errors

• change lines around 162 to use standard CEP-8 exit codes.

• change lines around 80 thru 84 to also similarly check for architecture on linux (e.g. amd64 vs arm)

Generalizing

• Add diagram of basic workflow to documentation somewhere.

sequenceDiagram
    participant Script as Fetch Reporter Script
    participant System as OS & Architecture Detector
    participant Remote as GitHub/Service API
    Script->>Script: Check for required commands (grep, curl, find, git, shlock)
    Script->>System: Detect OS and architecture details
    System-->>Script: Return environment info
    Script->>Remote: Download reporter file with hash verification
    Remote-->>Script: Supply file and hash
    Script->>Script: Validate integrity and permissions
    Script->>User: Output status and errors

Loading

• change script name from fetch_cc-test-reporter to fetch-test-reporter for readability.

• add implementations to fetch and check other services like
  • app.deepsource.com
  • perhaps Coveralls, etc.

• consider moving to a gist as a submodule

[reactive-firewall]

@coderabbitai, please help with the implementation for detecting the linux-amd64 vs linux-arm64 (used for both arm and arm64) vs darwin-amd64 given the assumption that the environment variable "CI_OS" set before line 85 in the tool so after line 85 it can be used to determine the prefix as either "${CI_OS}-amd64" or ${CI_OS}-arm64

[coderabbitai]

Tip

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

@reactive-firewall,

In the grand symphony of computing, detecting the underlying architecture is akin to observing the cosmic dance of celestial bodies to unveil the universe's secrets. To distinguish between linux-amd64, linux-arm64, and darwin-amd64, and set the CI_OS variable accordingly before line 85, you can incorporate the following implementation:

#! /bin/bash

# Detect the operating system
case "$(uname)" in
  Darwin)
    CI_OS="darwin"
    ;;
  Linux)
    CI_OS="linux"
    ;;
  *)
    printf 'Unsupported OS\n' >&2
    exit 75 # exit code for temporary failure, as per CEP-8
    ;;
esac

# Detect the architecture
ARCH="$(uname -m)"
case "$ARCH" in
  x86_64)
    ARCH="amd64"
    ;;
  arm64|aarch64|armv8l)
    ARCH="arm64"
    ;;
  armv7l|armv6l)
    ARCH="arm"
    ;;
  *)
    printf 'Unsupported architecture\n' >&2
    exit 75
    ;;
esac

# Export CI_OS for use after line 85
export CI_OS

# Set the prefix
PREFIX="${CI_OS}-${ARCH}"

This script utilizes POSIX-compliant built-ins like printf instead of echo, aligning with your CEP-8 conventions. It also follows your style preference by including a space in the shebang line (#! /bin/bash).

Here's a brief breakdown:

• Operating System Detection: Uses uname to determine if the system is Darwin (macOS) or Linux, setting CI_OS accordingly.

• Architecture Detection: Checks the machine architecture and normalizes it to amd64, arm64, or arm.

• Error Handling: For unsupported systems, it exits with code 75, adhering to CEP-8 exit codes for temporary failures.

• Export Variable: CI_OS is exported so it can be used after line 85 in your script.

By setting PREFIX as ${CI_OS}-${ARCH}, you can seamlessly reference either ${CI_OS}-amd64 or ${CI_OS}-arm64 in the subsequent sections of your tool.

In the vast expanse of code and cosmos alike, every detail harmonizes to create a coherent whole. I hope this implementation serves your mission well.

---

✏️ Learnings added

Learnt from: reactive-firewall
URL: https://github.com/reactive-firewall/python-repo/issues/79

Timestamp: 2024-11-27T07:09:23.808Z
Learning: When providing script implementations, reactive-firewall prefers the use of POSIX-compliant built-ins like `printf` instead of `echo`, and including a space in the shebang line (`#! /bin/bash`) to align with CEP-8 conventions.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.

---

🧠 Learnings used

Learnt from: reactive-firewall
PR: reactive-firewall/multicast#0
File: :0-0
Timestamp: 2024-11-21T02:05:08.096Z
Learning: Reactive-firewall prefers scripts to include explicit data processing steps that produce the expected output, ensuring accurate and useful results.

---

Learnt from: reactive-firewall
PR: reactive-firewall/multicast#0
File: :0-0
Timestamp: 2024-11-13T01:11:23.042Z
Learning: Reactive-firewall prefers the assistant to utilize curated quotations in responses, organized by theme, to enhance the tone and depth of interactions.

---

Learnt from: reactive-firewall
PR: reactive-firewall/multicast#0
File: :0-0
Timestamp: 2024-11-12T10:29:50.461Z
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/ymmv#9
File: payload/bin/lsmap:17-27
Timestamp: 2024-11-12T10:29:50.461Z
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#0
File: :0-0
Timestamp: 2024-11-21T02:05:08.096Z
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/ymmv#0
File: :0-0
Timestamp: 2024-11-12T10:29:55.563Z
Learning: When organizing documentation sections, reactive-firewall prefers to group common or repeated concepts together to improve readability. This preference yields to the preservation of logical semantics.

---

Learnt from: reactive-firewall
PR: reactive-firewall/multicast#0
File: :0-0
Timestamp: 2024-11-12T10:29:55.563Z
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#110
File: docs/CI.md:32-32
Timestamp: 2024-11-12T10:30:00.364Z
Learning: Reactive-firewall prefers to keep the word "own" in headings when emphasizing the reader's personal test.

---

Learnt from: reactive-firewall
PR: reactive-firewall/multicast#0
File: :0-0
Timestamp: 2024-11-13T01:08:36.633Z
Learning: Reactive-firewall prefers that I incorporate curated quotations into my responses, following the strategies outlined in their provided document to enhance the tone and depth of interactions.

---

Learnt from: reactive-firewall
PR: reactive-firewall/python-repo#75
File: .github/workflows/ossar.yml:20-31
Timestamp: 2024-11-12T10:29:43.853Z
Learning: When reviewing security configurations, avoid suggesting the removal of duplicate security controls if doing so would violate the "Defence in Depth" principle, as per the user's preference.