oliver006 / drone-cloud-run Goto Github PK

Looks like we have 327.0.0 and the latest out is 333.0.0.

Thanks in advance.

This is fairly new on the Cloud Run platform and would be great to add support for CloudSQL settings. For example, https://cloud.google.com/sdk/gcloud/reference/run/deploy#--add-cloudsql-instances

Drone 1.0 (don't know if previous Drone versions supported this) allows to read and set value of an environment variable through Drone setting, for example:

environment:
        DB_PASSWORD:
          from_secret: STG_DB_PASSWORD

It would be great to extend environment parsing logic to accept this pattern.

I got the following errors from Drone

2021/01/05 20:37:43 json.Unmarshal() err: json: cannot unmarshal number into Go value of type string
--
6 | 2021/01/05 20:37:43 os.Getenv(PLUGIN_ENVIRONMENT):

Deployment failed
--
32 | ERROR: (gcloud.beta.run.deploy) INVALID_ARGUMENT: Invalid JSON payload received. Unknown name "initializers" at 'service.metadata': Cannot find field.
33 | Invalid JSON payload received. Unknown name "initializers" at 'service.spec.run_latest.configuration.revision_template.metadata': Cannot find field.
34 | - '@type': type.googleapis.com/google.rpc.BadRequest
35 | fieldViolations:
36 | - description: "Invalid JSON payload received. Unknown name \"initializers\" at\
37 | \ 'service.metadata': Cannot find field."
38 | field: service.metadata
39 | - description: "Invalid JSON payload received. Unknown name \"initializers\" at\
40 | \ 'service.spec.run_latest.configuration.revision_template.metadata': Cannot\
41 | \ find field."
42 | field: service.spec.run_latest.configuration.revision_template.metadata
43 | 2021/01/05 20:37:44 runConfig() err: error: exit status 1

https://github.com/oliver006/drone-cloud-run/blob/master/main.go#L138

It is now GA. https://cloud.google.com/sdk/gcloud/reference/run/deploy

One pattern we're using and seems like it could be common is to deploy a service to multiple regions for geographic redundancy. A way to make this more concise in drone configs would be to accept an array of regions to deploy to. But I'm not sure whether drone conventions are opinionated about 2+ "things" happening within a single step. (If it discourages that, then ignore this...)

I could see someone implementing this either by increasing options to this plugin, or by having cloned steps running for each region in parallel.

Some Pros to changing the plugin that I see:

• More concise drone.yaml without needing to use dynamically generated config
• Could support features like rolling back all regions if a deploy to any one fails (and no need for user to ever implement this alone)

But of course some pros to keeping that logic out of the plugin:

• Less complex plugin (always good)
• More default flexibility for users to decide on order/parallelism/rollback rules

Can we please release a new latest tag to pick up the latest version of gcloud SDK?

The current latest tagged image is using Google Cloud SDK 261.0.0 and is very behind from the current stable version https://cloud.google.com/sdk/docs/release-notes.

I learned about this after a few days of troubleshooting following error:

Deploying new service...
failed
Deployment failed
ERROR: (gcloud.beta.run.deploy) INVALID_ARGUMENT: Invalid JSON payload received. Unknown name "initializers" at 'service.metadata': Cannot find field.
Invalid JSON payload received. Unknown name "initializers" at 'service.spec.run_latest.configuration.revision_template.metadata': Cannot find field.
- '@type': type.googleapis.com/google.rpc.BadRequest
  fieldViolations:
  - description: "Invalid JSON payload received. Unknown name \"initializers\" at\
      \ 'service.metadata': Cannot find field."
    field: service.metadata
  - description: "Invalid JSON payload received. Unknown name \"initializers\" at\
      \ 'service.spec.run_latest.configuration.revision_template.metadata': Cannot\
      \ find field."
    field: service.spec.run_latest.configuration.revision_template.metadata
2021/01/22 16:06:16 runConfig() err: error: exit status 1

I know we did this to ourselves by asking to change the gcloud command from beta to general availability (#7 - which is still probably a good default), but we have a new need now for the --tag argument during deploys, which is only available on the alpha/beta release tracks.

Wondering if it would make sense to make this configurable a setting, like track / release_track, or even just adding alpha or beta flags as options. Since features tend to stay in the alpha/beta tracks for many months, I think it could be worthwhile to preserve the ability to use them.

Google now has preview support for setting environment variable values from secrets in Secret Manager. On the command line, it works very similarly to environment variables, with the same suite of --clear-secrets / --set-secrets / --remove-secrets and --update-secrets.

We've been using it so far in by passing --set-secrets as a flag in addl_flags, but it becomes challenging when setting multiple variables, since we wind up with a long comma-delimited string that's hard to parse by humans. Given that secrets are set as key-value pairs, it seems like it would be more natural to use a map like we currently do with the environment option.

There are several formats supported with secrets, letting you set either environment variables from secrets, or setting the contents of a filepath to a secret value. But both are still fundamentally a map that could be represented in yaml:

secrets:
  ENV_1: secret_name:latest
  /mnt/path: secret_name:latest

I put together a PR to illustrate how we might go about this, but we can continue the discussion here. One potential conflict is that there already seems to be a top-level secrets array in the README example for Drone v0.8. I'm not familiar with the older syntax, so not sure whether that's a reserved key, or would cause problems in the newer version as well...

(There are also config maps that might be better represented this way as well, but we haven't used them so far.)