Sanitise service name and GCP-imposed rules about deploy-cloudrun HOT 6 CLOSED

Hi @erzz

I'm just one opinion, but I'm generally averse to client-side validation and manipulation of values. The server should really be enforcing this. If the allowed values were to change in the future, our Action would be unnecessarily limiting or modifying the resource name. We couldn't easily remove the validation, because that would be a breaking change for existing users.

Ideally GitHub Actions would have native functions for toLower and trim, but they do not.

I took a look at what gcloud does, and it looks like there is some client-side validation there:

$ gcloud run deploy "banana apple" --image gcr.io/vargolabs/gcr-cleaner --project vargolabs
ERROR: (gcloud.run.deploy) Invalid resource name [banana apple]. The name must use only lowercase alphanumeric characters and dashes, cannot begin or end with a dash, and cannot be longer than 63 characters.

Since deploy-cloudrun calls gcloud under the hood, you should be getting a similar error.

from deploy-cloudrun.

Hi @sethvargo !

Ideally GitHub Actions would have native functions for toLower and trim, but they do not

Amen to that! Extremely frustrating!. Likewise, no slug-variables, no short_sha's, and more ....

But isn't that the utility of an action? That it can remove the laborious and decidedly "un-DRY" workflows you are left with when working with these limitations and need to insert custom scripts here and there (in all kinds of horrible implementations) to handle things like this?

I mean:

• option 1: I pull in yet another action based on a 200mb docker image to create slugs :D
• option 2: I start hacking away with shell expansions, regex, cut and trim to get the dynamic naming to conform to the google (well RFC-819 I guess) standard
• option 3: the provider of the service knows the standard, has built the action, and can do the sanitisation inline if I opt-in with a boolean input?

We want to dynamically relate the name of the deployment to the branch for obvious reasons. But even when it comes to a release where we typically want to name a revision after the release tag v1.2.3 we again need to add in a sed to convert . to -

Just saying and of course I respect the decision either way!

from deploy-cloudrun.

But isn't that the utility of an action?

An action, but I don't think this action. I'm a big fan of the "do one thing and do it right" philosophy.

• option 1: I pull in yet another action based on a 200mb docker image to create slugs :D

I think it's possible to do this in significantly less than 200mb. It would require another action, but that seems to be pretty common in the Actions ecosystem. I can envision a "slugify" action being generally useful.

from deploy-cloudrun.

Untested, but something like this should work:

- id: 'slugify'
  run: |-
    node -c 'const input = "${{ my-input }}".replace(/W+/, '-').substring(0, 30); process.stdout.write("::set-output name=slug::"+x)'

from deploy-cloudrun.

Yes of course there are smaller / slimmer actions too :) But engineers pick generally the first that they find :)

Nice node version by the way!

But yes on the topic of do one thing and do it well ... surely validation and sanitisation are components of doing any kind of code well? :)

But sure you can also argue that actions are like functions and perhaps you would pass off validation to another function.

Would be interested to hear others opinions too - there is no rush in this :)

from deploy-cloudrun.

Hey @erzz - I feel like this needs to be a top-level function of GitHub Actions, since it's basic string manipulation and not specific to this action.

from deploy-cloudrun.