feat(warden): Upload findings to GCS via Workload Identity Federation#176
feat(warden): Upload findings to GCS via Workload Identity Federation#176
Conversation
Authenticate to GCP using OIDC workload identity and upload warden findings JSON to the warden-logs bucket after each PR scan. Files are stored as timestamped JSON under org/repo paths for downstream analysis. Co-Authored-By: Claude <noreply@anthropic.com> Agent transcript: https://claudescope.sentry.dev/share/1bzpd9bFJDpsTMflTcligEabMBUvuiHXGg3hoDQHdvI
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
Move GCP auth after warden scan with continue-on-error so auth failures don't block scanning. Guard rename/upload on findings-file being non-empty. Use env var instead of direct expression interpolation. Co-Authored-By: Claude <noreply@anthropic.com> Agent transcript: https://claudescope.sentry.dev/share/BKBjQj046vaZRSSn53ACddWCi8IA4OfcDBXrt63hk7U
Prevent upload failures (e.g. from failed GCP auth) from failing the entire workflow job. Co-Authored-By: Claude <noreply@anthropic.com>
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
| run: | | ||
| DEST="$RUNNER_TEMP/$(date -u +%Y-%m-%dT%H%M%SZ).json" | ||
| cp "$FINDINGS_FILE" "$DEST" | ||
| echo "path=$DEST" >> "$GITHUB_OUTPUT" |
There was a problem hiding this comment.
Absolute path may cause silent GCS upload failure
Medium Severity
The rename step writes the destination file to $RUNNER_TEMP which is an absolute path (e.g., /home/runner/work/_temp/...), and this absolute path is passed to upload-cloud-storage's path input. The google-github-actions/upload-cloud-storage action has documented issues with absolute paths and expects relative paths. Even if it doesn't error on Linux, the default parent: true behavior may cause the full directory tree (home/runner/work/_temp/) to be included in the GCS object name, resulting in files stored at an unexpected location instead of the intended gs://warden-logs/<org>/<repo>/<timestamp>.json. Because continue-on-error: true is set, any failure here would be completely silent, making the entire upload feature appear to work while never actually producing usable output.
Additional Locations (1)
Jeffreyhung
left a comment
Jeffreyhung
left a comment
There was a problem hiding this comment.
lgtm!
only one comment: should we include the PR number in the file name? will that make it easier for engs to lookup the logs? or does that not matter?
|
it's intentional, the bot that eats that will do so in bulk and mostly by repository |
2 participants
Upload warden structured findings JSON to a GCS bucket (
warden-logs) after each PR scan, using GCP Workload Identity Federation for authentication.This enables downstream analysis of warden findings — specifically to determine whether linters or other static analysis tools could catch issues that warden currently finds.
Files are stored at
gs://warden-logs/<org>/<repo>/<timestamp>.json.GCP prerequisites:
gha-warden@sac-prod-sa.iam.gserviceaccount.comneeds workload identity pool binding for this reporoles/storage.objectCreatoron thewarden-logsbucketAgent transcript: https://claudescope.sentry.dev/share/UvprGlpQKb1AA0zn-RInMqbwPfnbkAVnYTXlRLDB6zY