Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve and Generalize fetch_cc-test-reporter tool as gist submodule #79

Open
reactive-firewall opened this issue Nov 6, 2024 · 2 comments · May be fixed by #82
Open

Improve and Generalize fetch_cc-test-reporter tool as gist submodule #79

reactive-firewall opened this issue Nov 6, 2024 · 2 comments · May be fixed by #82
Assignees
Labels
CI Continuous Integration Tooling Code-Climate enhancement Linter Any linter tool or setting file enhancements
Milestone

Comments

@reactive-firewall
Copy link
Owner

Improve and Generalize fetch-test-reporter tool

Improvements

CEP-8 Compliance

Generalizing

  • 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 and perhaps Coveralls, etc.

  • consider moving to a gist as a submodule

@reactive-firewall reactive-firewall added enhancement Code-Climate Linter Any linter tool or setting file enhancements CI Continuous Integration Tooling labels Nov 6, 2024
@reactive-firewall reactive-firewall self-assigned this Nov 6, 2024
@reactive-firewall reactive-firewall added this to the Version 1.1.5 milestone Nov 27, 2024
@reactive-firewall
Copy link
Owner Author

@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

Copy link

coderabbitai bot commented Nov 27, 2024

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.

@reactive-firewall reactive-firewall linked a pull request Nov 27, 2024 that will close this issue
23 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CI Continuous Integration Tooling Code-Climate enhancement Linter Any linter tool or setting file enhancements
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant