Repository navigation
Integration: Support for GCP buckets #1140
Description
Is your feature request related to a problem?
We lack integration with Google GCP buckets, which hinders users from resolving private attachment URLs using their own credentials. This limits the potential for assessments involving these private URLs.
Describe the solution you'd like
-
Integrate Google GCP bucket support to allow users to provide service account JSON keys.
-
Enable private URL resolution using provided credentials.
-
Implement pathways for:
- Path A: Directly push URLs for Vertex providers.
- Path B: Sign URLs to public with a TTL of 24 hours for other providers.
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
Activity
[-]Bucket: Google GCP Bucket Integration[/-][+]Integration: Support for GCP buckets[/+]kartpop commentedon Aug 20, 2026
A few additional implementation details/constraints worth capturing beyond the original description:
Abstraction requirements
convert_to_public_url-style utility taking source URLs + destination provider and returning usable URLs, acting as a no-op when the input is already public.BucketProviderclass hierarchy mirroring the existingLLMProviderpattern (GCS first, S3 later).Path A constraint: the bucket referenced in the service-account credential must be the same bucket the attachments live in.
TTL: should be configurable (1h/24h both discussed) rather than fixed at 24h.
Testing plan: validate both GCS pathways with small standalone scripts — insert a service-account credential row in the credentials table (mimicking partner setup), drop a test JPG in the bucket, and verify read access via (a) direct URI to Vertex and (b) signed URL. S3 doesn't need retesting since the signed-URL flow is already proven.
fyi: @vprashrex
Related: PR #1138 (open), PR #1131 (open)
github-actions commentedon Aug 26, 2026
🎉 This issue has been resolved in version 1.5.0-main.12 🎉
The release is available on GitHub release
Your semantic-release bot 📦🚀