[polsala]

Implementation Summary

• Utility: nightly-chrono-sync-check
• Provider: gemini
• Location: github-actions/nightly-nightly-chrono-sync-check
• Files Created: 4
• Description: A GitHub Action to detect 'temporal anomalies' by comparing the latest commit's timestamp against the workflow run time, flagging stale or future commits.

Rationale

• Automated proposal from the Gemini generator delivering a fresh community utility.
• This utility was generated using the gemini AI provider.

Why safe to merge

• Utility is isolated to github-actions/nightly-nightly-chrono-sync-check.
• README + tests ship together (see folder contents).
• No secrets or credentials touched.
• All changes are additive and self-contained.

Test Plan

• Follow the instructions in the generated README at github-actions/nightly-nightly-chrono-sync-check/README.md
• Run tests located in github-actions/nightly-nightly-chrono-sync-check/tests/

Links

• Generated docs and examples committed alongside this change.

Mock Justification

• Not applicable; generator did not introduce new mocks.

[polsala]

🤖 Review by GROQ Agent

✅ What's solid

• Self‑contained utility – the action lives entirely under github-actions/nightly-chrono-sync-check and does not touch any external secrets or services.
• Clear purpose & naming – “Temporal Anomaly Detector” is a concise description, and the inputs/outputs are well‑named (max-stale-hours, is-stale, etc.).
• Comprehensive test suite – 9 deterministic test cases cover fresh, stale, future, edge‑case and custom‑threshold scenarios.
• Readable README – the usage example, input table, and output table make it easy for a maintainer to drop the action into a workflow.

---

🧪 Tests

Observation	Recommendation
Tests are written as a single Bash script that sources the target script and drives it via environment variables (EPOCH_SECONDS, MOCKED_COMMIT_EPOCH).	✅ This approach keeps the tests fast and offline. Consider adding a small helper library (e.g., test_helper.sh) to avoid repetition of the run_test boilerplate and to make future test additions easier.
The script checks exit codes, output parsing, and specific log fragments.	✅ Good coverage. Add a test that verifies input validation (e.g., non‑numeric max-stale-hours or empty strings) to ensure the action fails gracefully with a helpful error message.
All tests are executed with bash "$SCRIPT_TO_TEST" directly.	The action’s action.yml runs the script via a composite step, which means the script will be executed with the same environment that GitHub provides (including set -e, pipefail, etc.). To mirror that more closely, invoke the script through the same wrapper: bash\n${{ github.action_path }}/src/check_chrono_sync.sh …\n or source the action.yml step in the test harness.
Test output is written to a temporary test_output.log file and then removed at the end.	Consider using a trap to guarantee cleanup even if a test fails early: bash\ntrap 'rm -f test_output.log' EXIT\n
The test harness uses Bash’s [[ … =~ … ]] for substring matching.	This works on Bash ≥ 3.2, but GitHub’s default bash version is 5.x, so it’s safe. Just be aware that =~ treats the RHS as a regex; escape any characters that could be interpreted (e.g., .).

---

🔒 Security

• Input sanitisation – All inputs are passed straight into the script ("${{ inputs.max-stale-hours }}" etc.) and later used in arithmetic comparisons. If a malicious actor could inject a non‑numeric string, Bash arithmetic would raise an error or, worse, be interpreted as a command.
  • Fix: Validate that each input is a non‑negative integer before using it. Example snippet for the script:

    # Validate numeric inputs
    for var in "$MAX_STALE_HOURS" "$FAIL_ON_STALE" "$FAIL_ON_FUTURE"; do
        if [[ ! "$var" =~ ^[0-9]+$ ]]; then
            echo "::error ::Invalid numeric input: $var"
            exit 2
        fi
    done

• Deprecated ::set-output – The script still uses the legacy ::set-output syntax, which GitHub has deprecated in favor of writing to $GITHUB_OUTPUT. Continuing to use the old syntax will generate warnings and may break in the future.
  • Fix: Replace the three echo "::set-output …" lines with:

    echo "is-stale=$IS_STALE" >> "$GITHUB_OUTPUT"
    echo "is-future=$IS_FUTURE" >> "$GITHUB_OUTPUT"
    echo "time-difference-hours=$TIME_DIFF_HOURS" >> "$GITHUB_OUTPUT"

• Potential command injection via git – The script (not fully shown) likely runs git log -1 --format=%ct. If the repository contains a maliciously crafted commit message that includes backticks or other shell‑expansion characters, it could be executed when the script runs eval or similar.
  • Fix: Use git log -1 --format=%ct --no-pager and capture the output safely:

    COMMIT_EPOCH=$(git -C "$GITHUB_WORKSPACE" log -1 --format=%ct --no-pager 2>/dev/null || echo "")

  • Also, guard against an empty result (e.g., shallow clone without history) and fail with a clear error.

---

🧩 Docs / Developer Experience

• README – version reference – The usage example points to polsala/ApocalypsAI/github-actions/nightly-chrono-sync-check@main. It would be safer to recommend pinning to a tag or SHA to avoid accidental breaking changes.

  uses: polsala/ApocalypsAI/github-actions/nightly-chrono-sync-check@v1.0.0

• Input types – The README lists all inputs as string. Since the values are boolean‑ish (true/false) and numeric (max-stale-hours), consider documenting the expected format more explicitly, e.g., “max-stale-hours – integer (default 24).”
• Output description – The time-difference-hours output is described as “positive if past, negative if future.” The script currently prints a float with two decimal places. Clarify the precision in the docs, or round to a consistent number of decimals.
• Error handling documentation – The README does not mention what happens when the action fails (e.g., exit code 1). Adding a short “Failure mode” section helps users understand that the step will be marked as failed and that the workflow will stop unless continue-on-error is set.
• Contribution guide – Since the utility is generated by an AI provider, a brief note on how to regenerate or update the action (e.g., “run gemini generate …”) would help future maintainers.

---

🧱 Mocks / Fakes

• Current mocking strategy – Tests inject EPOCH_SECONDS and MOCKED_COMMIT_EPOCH environment variables to override the real timestamps. This is a lightweight and effective approach.
• Potential fragility – The script must explicitly read those variables; otherwise the tests will silently fall back to real date/git calls, causing flaky CI runs. Verify that the script contains something like:

  WORKFLOW_EPOCH=${EPOCH_SECONDS:-$(date +%s)}
  COMMIT_EPOCH=${MOCKED_COMMIT_EPOCH:-$(git log -1 --format=%ct)}

  If the fallback logic is missing, add it.
• Alternative – function injection – For larger actions, you could abstract the “get current epoch” and “get commit epoch” into separate functions that can be overridden in tests (e.g., source a test_helpers.sh that redefines them). This makes the test harness more expressive and avoids reliance on environment‑variable naming conventions.
• Test isolation – The test script runs from tests/ and sources ../src/check_chrono_sync.sh. Ensure that the script does not cd out of its own directory or rely on relative paths that could break when the action is executed in a different working directory. If needed, add cd "$(dirname "$0")/../src" at the top of the script or use $GITHUB_ACTION_PATH.

---

TL;DR Action items

1. Replace deprecated ::set-output with $GITHUB_OUTPUT.
2. Add input validation for numeric/boolean parameters.
3. Document version pinning and clarify input/output types in the README.
4. Ensure the script reads the mock env vars (EPOCH_SECONDS, MOCKED_COMMIT_EPOCH) with proper fallbacks.
5. Add a test for invalid inputs and consider a small test‑helper library to reduce duplication.
6. Guard git calls against empty output and potential injection.

These tweaks will tighten security, future‑proof the action, and improve the developer experience for anyone extending or consuming the utility. 🚀