Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.github/workflows/data-update-partners-data.yml:
- Around line 57-64: The script uses set -euo pipefail so a failing curl exits
the shell before the subsequent "if [ $? -ne 0 ]" can run; replace the current
pattern where you capture curl into response with a conditional capture (e.g.,
run curl as part of an if/else or use "if ! response=$(curl ...); then ...; fi")
so failures are handled, logging the warning and continuing rather than letting
set -e terminate the job; update the block that contains "response=$(curl
--silent --fail --request GET ...)" and the following "if [ $? -ne 0 ]" to this
conditional-style error handling and keep the existing echo "::warning::Failed
to fetch ${partner_type} partners" and continue behavior.

---

Nitpick comments:
In @.github/workflows/data-update-partners-data.yml:
- Around line 119-122: The maintainer fetch using the curl + jq pipeline (the
Contacts search call) will cause an immediate hard exit under set -euo pipefail
if curl --fail fails; either decide to keep hard failure or make it graceful
like the partner fetch: run the curl command in a guarded block that captures
stdout/stderr (or return code) from the Contacts search call, check its exit
status before piping to jq, and on failure log a clear warning and fall back to
cached maintainer data (or skip/continue) instead of letting the script exit;
update the block that invokes curl and jq for Contacts (the maintainer fetch) to
mirror the partner-fetch error handling pattern so failures are handled
deterministically.

Verify each finding against the current code and only fix it if needed.

Duplicate comments:
In @.github/workflows/data-update-partners-data.yml:
- Around line 127-133: The avatar lookup can cause the script to exit under set
-e if the curl|jq pipeline fails; change the assignment to make the lookup
genuinely best-effort by swallowing non-zero exit from the pipeline—for example
update the assignment for avatar_url to run the pipeline with a trailing "||
true" inside the command substitution (e.g., avatar_url=$(curl -s -H
"Authorization: token $GH_TOKEN" "https://api.github.com/users/$username" | jq
-r '.avatar_url' || true)) and keep the existing null/empty check and fallback
that sets avatar_url="" and emits the warning; reference variable avatar_url and
the curl|jq pipeline in your change.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.github/workflows/data-update-partners-data.yml:
- Around line 120-124: The maintainers fetch curl command that calls
"https://www.zohoapis.eu/bigin/v2/Contacts/search?..." using Authorization:
Zoho-oauthtoken $ACCESS_TOKEN currently runs under set -euo pipefail and will
cause an immediate hard failure on network/HTTP errors; either make its behavior
match the partners fetch by capturing the curl/jq exit status and emit a warning
+ continue (e.g., check curl exit code, log a warning and skip processing the
maintainers loop) or intentionally document the hard-fail design with an inline
comment above the curl explaining why maintainers must fail fast; update the
block that pipes to jq and the while-read loop (the "maintainers fetch"
pipeline) to implement the chosen behavior.

In `@scripts/days_since_last_commit.py`:
- Around line 44-47: The code unconditionally indexes into the GraphQL response
(data["data"]["organization"]["pinnedItems"]["nodes"]) which can raise KeyError
if the API returns errors or the organization is missing; after data = r.json()
(in the function handling this request), validate the response by checking for
an "errors" key and that data.get("data") and data["data"].get("organization")
and the nested "pinnedItems" and "nodes" keys exist and are not None, and if not
raise or log a clear exception/message that includes the raw response (or error
details) instead of letting a KeyError propagate; update the nodes extraction
and the return path to handle an empty/missing nodes list gracefully.

---

Nitpick comments:
In `@scripts/days_since_last_commit.py`:
- Around line 88-96: The CLI currently reads the token as a positional argument
in main(), exposing it in process listings; change parsing so the GitHub token
is read from an environment variable (e.g., GITHUB_TOKEN) instead of a
positional arg: update main() to accept only ORG and USER as required positional
args (or make TOKEN optional) and fetch token = os.environ.get("GITHUB_TOKEN")
when not provided on the CLI, and if token is still missing print the usage
indicating to set GITHUB_TOKEN and exit; update the usage message and any
references to the token variable to reflect the env fallback to avoid passing
secrets via process args.
- Around line 78-79: Replace the broad "except Exception as e" in the block that
prints "[WARN] {name}: {e}" with a narrowed exception tuple that targets
expected failures (e.g., requests.exceptions.RequestException and
json.JSONDecodeError) so only HTTP/JSON errors are caught; update the except
clause to "except (requests.exceptions.RequestException, json.JSONDecodeError)
as e" (and add the necessary imports if missing) and leave other unexpected
exceptions to propagate.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.github/workflows/data-update-partners-data.yml:
- Around line 147-158: The workflow currently treats days_since == "-1" (from
armbian.github.io/scripts/days_since_last_commit.py) as "no activity" but that
value also signals lookup failures; update the helper
(days_since_last_commit.py) to return a distinct error signal (e.g., exit
non-zero or print a different sentinel like "ERROR") on failure, and then change
the workflow logic that reads the days_since variable to check for that error
signal first (and fail or skip the update) before mapping "-1" to "no activity";
ensure the jq enrichment step (. + {Avatar: $avatar, Days_since_last_activity:
($days | tonumber)}) only receives numeric values or is skipped when an error
sentinel is present.
- Around line 56-62: The workflow currently treats curl failures in the for loop
over partner_type (Platinum Gold Silver) as warnings and continues, but the
subsequent `length > 0` check can still pass and cause a partial `partners.json`
to be published; change the logic in the loop that sets `response` (where the
curl call is made for each partner_type) to fail the job on any curl error
(e.g., exit non-zero or set a flag and break) so that a transient fetch error
prevents publishing, or alternatively ensure `response` is explicitly
unset/empty on failure so the later `length > 0` checks correctly detect missing
data; apply the same fix to the duplicate block at lines handling the other
partner type fetch (the second curl loop referenced in the comment).
- Around line 138-145: The avatar lookup can cause the whole step to fail under
set -euo pipefail; make the lookup best-effort by running the curl|jq pipeline
in a way that its failures don't trigger exit (e.g., append || true or capture
output via a subshell that returns success) and then validate avatar_url as
before; update the use of avatar_url (the variable produced from curl -H
"Authorization: token $GH_TOKEN" ... | jq -r '.avatar_url') so any curl/jq error
yields an empty string rather than a non-zero exit status, preserving the
existing null/empty checks and warning log.