Unlike nearly every automated build system, Google Cloud Build does not set environment variables inside of the running build docker containers automatically with the build context information. Instead it has "Substitution Variables" that a developer has to explicitly pass as environment variables. This makes tools that customize information based on the build environment impossible without special configuration to pass the default substitution variables as environment variables to each build step.

https://cloud.google.com/cloud-build/docs/configuring-builds/substitute-variable-values

By default the default substitution variables should be available as environment variables in the build containers. Maybe google could provide an option to disable that functionality for extremely sensitive build steps, but if this new functionality isn't the default behavior, it means Cloud Build is not on feature par with most other build systems and tools like "env-ci" will never work with them without special configuration (defeating the purpose of the library).

https://github.com/pvdlg/env-ci/pull/97#issuecomment-540040921

Right now, it is possible to define maintenance windows for some GCP resources like Cloud SQL instances and GKE clusters at the resource level:
- https://cloud.google.com/sql/docs/mysql/instance-settings#maintenance-window-2ndgen
- https://cloud.google.com/kubernetes-engine/docs/how-to/maintenance-window

CloudSQL even allows to define relative maintenance timing settings
between instances in the same project: https://cloud.google.com/sql/docs/mysql/instance-settings#maintenance-timing-2ndgen

> The relative timing of updates is not observed between projects; if you have instances with an earlier timing setting in a different project than your instances with a later timing setting, Cloud SQL makes no attempt to update the instances with the earlier timing setting first.

However, I like to separate staging/pre-production and production environments in independent projects.

It would be awesome if GCP provided relative canary and stable maintenance timing settings for projects attached to a same organization, maybe at the folder level.

That way, I'd be able to define staging/pre-production projects as "canary" and production as "stable" to get updates earlier in the former.
When disruptions would be noticed in staging/pre-production during maintenance, fixes could be implemented or on-call could be prepared when the same maintenance will happen in production.

Hey I'm a student and relatively new to cloud and as a student I CAN NOT afford a credit card and it's not easy to get credit card in my country when you are still a student.
I understand GCP can't accept debit cards due to VBV or requiring OTP for payment which conflicts with auto pay but that should not be the reason to kick out user as a whole from the service if they can't verify with a credit card?

What if GCP instead allowed user to verify using debit cards and let the user buy a subscription pack instead ?
Like the user creates a compute engine then it asks user to buy the subscription , the user can also pay in advance for a month where user manually pay the amount and not auto pay? If user didn't pay amount for next month then ofc there account will get disabled or whatever but it would be really nice and appreciated if there's another alternative to the credit card thingy.

I used GCP with free tier for a month and really loved it, it's exactly what I was looking for, but my account got terminated because I didn't verified my account with credit card.
(I'm sorry if Its already been posted or if I posted it at wrong thread)

Cloud Filestore is a mountable NFS with good performance. It has two tiers, currently $0.30/GB/mo for super fast and $0.20/GB/mo for fast. Our use case is 100TB of 500k-10MB files that gets randomly accessed, but has a very low speed and IOPS requirement; we are paying a mere $0.04/GB/mo to host this on an old NetApp filer at Rackspace, we don't care about the speed just that it works and has reasonable access latency. It would be nice if Google had a slower tier of NFS that was cheaper and let people with large file repositories (that for whatever reason can't get on GCS yet) but low performance requirements to use your cloud based NFS solution. Currently this is the only thing preventing us from moving our whole Compute load to GCP: we can't replace our Filer for anywhere near the price in any Cloud environment. Filestore looks great functionally, but has way more performance than we need, for way more cost.

I know that right now Cloud Build is still in Beta but I think that throwing out feedback is always helpful.

After a build has finished, a new container is created in the container registry.

The problem is that from there a user has to go completely somewhere else to create a deployment logic.

In our specific case we're toying with deploying to Instance Groups based on those containers but I'd like to have a wizard-like UI that guide me through the whole process and available options.

For example:

1. Set up a trigger from Cloud Build
2. Wizard: What you want to do with the build once it's finished?
3a. Deploy to a VM
3b. Deploy to an Instance group
3c. Deploy to App Engine
...

And so on. And given the option, provide the UI needed to guide the user.

Of course there isn't a need to cover *every possible scenario* but at least the most common one and the one that GCP suggest as "good practice".