Dataset cache-key step silently succeeds when gin is unreachable

[AxelNoun]

Issue draft — dataset_hash step silently succeeds on gin failure

Do not fold into #1891. Separate issue.

Summary

The Get ephy_testing_data current head hash step in IO / cache workflows stays green when git ls-remote against gin fails (e.g. HTTP 403), writing an empty dataset_hash and degrading the cache key to ${{ runner.os }}-datasets-.

Where

Same pattern in:

• .github/workflows/io-test.yml (lines 41–45)
• .github/workflows/caches_cron_job.yml (lines 70–73)
• .github/workflows/plexon2-testing.yml (lines 32–36)

- name: Get ephy_testing_data current head hash
  id: ephy_testing_data
  run: |
    echo "dataset_hash=$(git ls-remote https://gin.g-node.org/NeuralEnsemble/ephy_testing_data.git HEAD | cut -f1)" >> $GITHUB_OUTPUT

Mechanics (verified)

The step's exit status comes from echo, not from the command substitution. set -e alone does not catch it either, because git's failure is masked by cut succeeding. pipefail is required.

Form	Exit code
echo "x=$(git … | cut -f1)" >> $GITHUB_OUTPUT	0 — silent
set -eu + variable assignment	0 — still silent
set -euo pipefail + variable assignment	128 — loud

Observed in run 30934750446: gin returned 403 on git ls-remote, the step still concluded success, cache key became Linux-datasets-, and every subsequent IO test errored on datalad fetch with the same 403.

Proposed fix

- id: dataset_hash
  run: |
    set -euo pipefail
    hash="$(git ls-remote https://gin.g-node.org/NeuralEnsemble/ephy_testing_data.git HEAD | cut -f1)"
    if [ -z "$hash" ]; then
      echo "::error::could not resolve ephy_testing_data HEAD — refusing to build a degenerate cache key"
      exit 1
    fi
    echo "dataset_hash=$hash" >> "$GITHUB_OUTPUT"

Apply consistently in the three workflows listed above (or factor into a composite action later).