pass arguments to gcloud deploy #357
Conversation
| if [ $# != 1 ]; then | ||
| echo Usage: $0 [project_id] | ||
| if (( $# < 1 )); then | ||
| echo Usage: $0 PROJECT_ID [options] |
There was a problem hiding this comment.
What options are potentially interesting here? I've never had to add anything else, so just wondering... I'm a bit worried about making this too flexible since ideally the cloud-deploy part would be very regular/consistent...
There was a problem hiding this comment.
I looked into it, I don't think any. I made some assumptions based on the names of some things but I don't think they're relevant anymore, so it's only the service account then.
|
I missed something I think -- what about the service account? Really
trying to deprecate those so I'm not sure in this case why they'd be
necessary?
…On Tue, Jun 7, 2022 at 9:02 AM Noureddine ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In dashboard/deploy_dashboard_gcloud
<#357 (comment)>:
> @@ -1,7 +1,7 @@
#!/bin/bash -e
-if [ $# != 1 ]; then
- echo Usage: $0 [project_id]
+if (( $# < 1 )); then
+ echo Usage: $0 PROJECT_ID [options]
I looked into it, I don't think any. I made some assumptions based on the
names of some things but I don't think they're relevant anymore, so it's
only the service account then.
—
Reply to this email directly, view it on GitHub
<#357 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIEPD2QCNEQYAVJOFFTTUTVN5XAVANCNFSM5YDKQPQQ>
.
You are receiving this because your review was requested.Message ID:
***@***.***>
|
|
It's the runtime service account (https://cloud.google.com/functions/docs/securing/function-identity#runtime_service_account) for the cloud function. An instance of a cloud function inherits its permissions from either the defined service account or the app engine default account if unspecified. So by specifying the service account the cloud functions are associated with, their access to the GCP project can be controlled, and reduced from the everything access they have by default at the moment. |
|
Sure, but when does this come up? I'm basically wondering if this should
be a required thing or is optional really ok. Practically speaking this
script was more meant for a quickstart, but I was expecting the "real"
deployments to go through terraform.
Anyway -- nothing specifically wrong with this change, more just
questioning the overall workflow!
…On Tue, Jun 7, 2022 at 9:55 AM Noureddine ***@***.***> wrote:
It's the runtime service account (
https://cloud.google.com/functions/docs/securing/function-identity#runtime_service_account)
for the cloud function. An instance of a cloud function inherits its
permissions from either the defined service account or the app engine
default account if unspecified.
So by specifying the service account the cloud functions are associated
with, their access to the GCP project can be controlled, and reduced from
the everything access they have by default at the moment.
—
Reply to this email directly, view it on GitHub
<#357 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIEPD66AFAT3MY7UQYFFFDVN55HNANCNFSM5YDKQPQQ>
.
You are receiving this because your review was requested.Message ID:
***@***.***>
|
I needed this so I can deploy the gcloud functions with the non-default service account (the default service account has editor role over a project by default).
Just passes the arguments onto the
gcloud deploycall, so gcloud deploy parameters can be used. I only neededservice-account, but figured power users may want to modify some of the other parameters too