You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When trying to use the deploy step in deploy-cloud-functions, it ignores the service_account_email setting.
We've created a new service account (SA) for our project in GCP. We've been trying to deploy it, but no matter what we do it will not deploy using the SA specified. It will always revert to the default SA (called 'Compute Engine default service account' on Google Cloud). The service_account_email seems to be ignored.
Expected behavior
Setting the service_account_email in deploy-cloud-functions should use the specified SA instead of the standard one.
I've tried using v3 of deploy-cloud-functions as well, replacing service_account_email with service_account instead. Unfortunately it gives me the exact same behaviour as described.
Both workload_identity_provider and service_account in the 'auth' step are defined, but I changed them in this bug report for security reasons.
Observed behavior
The default service account is used, service_account_email is ignored.
TL;DR
When trying to use the deploy step in
deploy-cloud-functions
, it ignores theservice_account_email
setting.We've created a new service account (SA) for our project in GCP. We've been trying to deploy it, but no matter what we do it will not deploy using the SA specified. It will always revert to the default SA (called 'Compute Engine default service account' on Google Cloud). The
service_account_email
seems to be ignored.Expected behavior
Setting the
service_account_email
indeploy-cloud-functions
should use the specified SA instead of the standard one.I've tried using v3 of
deploy-cloud-functions
as well, replacingservice_account_email
withservice_account
instead. Unfortunately it gives me the exact same behaviour as described.Both
workload_identity_provider
andservice_account
in the 'auth' step are defined, but I changed them in this bug report for security reasons.Observed behavior
The default service account is used,
service_account_email
is ignored.Action YAML
Log output
No response
Additional information
No response
The text was updated successfully, but these errors were encountered: