Can HumDay connect to Google Cloud Deploy?

Yes. HumDay reads Google Cloud Deploy's own published API description and derives the operations from it, so there is no hand-built connector to wait for. 24 operations are documented.

Do I need to write code to automate Google Cloud Deploy?

No. You describe the outcome you want in plain words. HumDay agrees a contract with you, writes the program, and shows you a test run before anything touches your Google Cloud Deploy account.

What can HumDay do in Google Cloud Deploy?

15 of the 24 documented operations change something in Google Cloud Deploy, and 9 read from it. HumDay only ever uses the specific operations your approved contract needs.

Is my Google Cloud Deploy account safe?

Your credentials are stored encrypted and are never shown in chat, code, or logs. Every run is limited to the operations you explicitly approved, and anything that writes to Google Cloud Deploy is held behind that approval.

Automate Google Cloud Deploy

HumDay reads Google Cloud Deploy’s own published API description and derives 24 operations from it. Describe the outcome you want in plain words — you get a program that is written, proven on real data, and run for you.

What HumDay can do in Google Cloud Deploy

15 documented operations change something in Google Cloud Deploy.

POSTCreates a new Target in a given project and location./v1/{parent}/targets
POSTCreates a new Release in a given project and location./v1/{parent}/releases
POSTCreates a new Rollout in a given project and location./v1/{parent}/rollouts
POSTCreates a new DeliveryPipeline in a given project and location./v1/{parent}/deliveryPipelines
DELETEDeletes a single Target./v1/{name}
PATCHUpdates the parameters of a single Target./v1/{name}
POSTStarts asynchronous cancellation on a long-running operation./v1/{name}:cancel
POSTAbandons a Release in the Delivery Pipeline./v1/{name}:abandon
POSTAdvances a Rollout in a given project and location./v1/{name}:advance
POSTApproves a Rollout./v1/{name}:approve
POSTTerminates a Job Run in a given project and location./v1/{name}:terminate
POSTRetries the specified Job in a Rollout./v1/{rollout}:retryJob
POSTIgnores the specified Job in a Rollout./v1/{rollout}:ignoreJob
POSTSets the access control policy on the specified resource./v1/{resource}:setIamPolicy
POSTReturns permissions that a caller has on the specified resource./v1/{resource}:testIamPermissions

What HumDay can read from Google Cloud Deploy

These are the operations a schedule or a trigger can watch.

GETGets details of a single Target./v1/{name}
GETGets the access control policy for a resource./v1/{resource}:getIamPolicy
GETLists information about the supported locations for this service./v1/{name}/locations
GETLists JobRuns in a given project and location./v1/{parent}/jobRuns
GETLists Targets in a given project and location./v1/{parent}/targets
GETLists operations that match the specified filter in the request./v1/{name}/operations
GETLists Releases in a given project and location./v1/{parent}/releases
GETLists Rollouts in a given project and location./v1/{parent}/rollouts
GETLists DeliveryPipelines in a given project and location./v1/{parent}/deliveryPipelines

How automating Google Cloud Deploy works

Describe the outcome. Say what you want to happen, in your own words. No node graphs, no field mapping.
Approve the contract. HumDay writes down exactly what it will do, what it will touch, and what it will never do. You approve it before anything is built.
See it proven. The program runs and shows you the result before it is allowed near your live Google Cloud Deploy account.
Grant access, then go live. You approve the specific Google Cloud Deploy operations it may use — and only those.