Skip to content

feat: Add Google Access Token support for GCP actions#39

Merged
tdabasinskas merged 5 commits into
datolabs-io:mainfrom
tfhartmann:use-user-token
May 22, 2026
Merged

feat: Add Google Access Token support for GCP actions#39
tdabasinskas merged 5 commits into
datolabs-io:mainfrom
tfhartmann:use-user-token

Conversation

@tfhartmann
Copy link
Copy Markdown
Contributor

@tfhartmann tfhartmann commented May 19, 2026

Introduce a Google Access Token field extension for GCP authentication and enable the usage of user OAuth tokens in GCP actions. This enhances flexibility in authentication methods for GCP services.

Please do give this a through review, as I leaned pretty heavy on AI to write this.

tfhartmann and others added 2 commits May 19, 2026 16:44
Co-authored-by: Copilot <copilot@github.com>
Co-authored-by: Copilot <copilot@github.com>
@tfhartmann tfhartmann requested a review from a team as a code owner May 19, 2026 21:18
Revert to an earlier version of @backstage/backend-plugin-api to maintain compatibility with the current Backstage setup.
@tdabasinskas
Copy link
Copy Markdown
Member

Nice work on this overall — the feature's useful. The main thing I'd want sorted before merge is how the access token is handled. There are a couple of spots where it can end up persisted, and one option that doesn't actually work.

First, the field extension calls both setSecrets and onChange(token). setSecrets is the right one — scaffolder secrets stay in memory and aren't persisted. But onChange(token) writes the token into the form value (parameters.googleToken), and parameters do get saved to the scaffolder database. The hidden widget and review.show: false only hide it in the UI, not in storage. Can we drop the onChange call and rely just on setSecrets?

Same thing with the explicit token action input — action inputs are part of the saved task spec, and the README example feeds it from ${{ parameters.googleToken }}, which is persisted. I'd lean toward dropping the token input entirely and just reading ctx.secrets.googleAccessToken. It keeps one safe path and removes the footgun.

Last one: the secretKey option doesn't work end to end. The field lets you rename the key via ui:options.secretKey, but auth.ts hardcodes secrets.googleAccessToken. So if anyone sets a custom key, the action never finds the token and silently falls back to ADC — no error, just the wrong identity. Simplest fix is probably to drop the option and always use googleAccessToken.

I also regenerated yarn.lock and downgraded backend-plugin-api, as CI was failing.

@tfhartmann
Copy link
Copy Markdown
Contributor Author

Awesome I'll work on these updates and push em to the branch!

@tfhartmann
Copy link
Copy Markdown
Contributor Author

@tdabasinskas take a look at this and let me know what you think. I was able to test in my sandbox and was able to create all 3 resources! 🎆

Copy link
Copy Markdown
Member

@tdabasinskas tdabasinskas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Appreciate the contribution!

@tdabasinskas tdabasinskas merged commit 1e40fdd into datolabs-io:main May 22, 2026
8 checks passed
@tfhartmann tfhartmann deleted the use-user-token branch May 22, 2026 12:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants