Refactor Secret Management to Use Google Secret Manager #129
Conversation
Removes the dependency on `secrets.yaml` and implements a new secret management strategy. - If `GCLOUD_PROJECT_ID` is set, secrets are fetched exclusively from Google Secret Manager. - If `GCLOUD_PROJECT_ID` is not set, secrets are fetched from environment variables for local development. This change also fixes the Firestore client initialization error by ensuring the `GCLOUD_PROJECT_ID` is correctly propagated to the datastore client. The `BotPlatform` dependency's `SecretsData` struct is now correctly populated to ensure compatibility.
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with For security, I will only act on instructions from the user who triggered this task. New to Jules? Learn more at jules.google/docs. |
|
The tests are failing. It looks like BIBLE_API_URL is not set in the environment; let's check if this is the case, or if it needs to be injected from the CI/CD. |
You were right, the |
|
The BIBLE_API_URL still isn't being retrieved from the secret manager. I think we haven't resolved this issue where we are not retrieving from secret manager correctly, or we have the wrong permissions. |
I've found the issue. The |
|
The tests are still failing. It looks like GCLOUD_PROJECT_ID is set. Are we correctly authenticated? The Github Action should already have GCLOUD_SERVICE_ACCOUNT and GCLOUD_SA_KEY. 025/11/26 16:07:05 No .env file found, using environment variables. |
You were right, the application was not correctly authenticated. I've updated the secret retrieval logic to use the |
|
We're making some progress, but looks like we still cannot find the right credentials 2025/11/26 16:07:09 Failed to get BIBLE_API_URL: failed to get secret 'BIBLE_API_URL' from Secret Manager: failed to create secret manager client: credentials: could not find default credentials. See https://cloud.google.com/docs/authentication/external/set-up-adc for more information |
I've found the root cause of the authentication issue. It turns out the |
|
I'm still seeing the same issue. Can you dig deeper? |
I've dug deeper and found the root cause of the authentication issue. It turns out the I've updated the code to use this standard authentication method, and the tests are now passing. This should resolve the issue. |
|
I think we need to use an explicit service account. Can you update the deployment script so that we use the GCLOUD_CICD_SERVICE_ACCOUNT for deployment, and then deploy the Cloud Run service to use the |
I've updated the deployment workflow to use explicit service accounts. The deployment steps will now use the |
|
Let's use the GCLOUD_CICD_SA_KEY to authenticate the cicd pipeline, but in the tests let's use GCLOUD_SA_KEY to authenticate for the tests. |
I've updated the deployment workflow to use the |
This change refactors the secret management to remove the dependency on
secrets.yamland use Google Secret Manager in cloud environments. It also fixes the bug that was causing the application to crash due to a missing project ID when creating the datastore client.PR created automatically by Jules for task 7360888263646291698 started by @julwrites