search

google-apis-rs / google-cloud-rs

Asynchronous Rust bindings for Google Cloud Platform APIs.
176 stars 48 forks source link

Support for Cloud Tasks #24

Open msdinit opened 4 years ago

msdinit commented 4 years ago

Hi! Hope you're accepting pull requests with new integrations.

This is an integration to Cloud Tasks, pretty minimal for now - it allow getting queue by name and creating tasks. I tried to follow your conventions, to the best of my understanding, but do tell me if you prefer something changed!

One quirk I bumped into is the requirement for custom routing metadata here and here - could not find this anywhere in the docs, so I basically followed what Python implementation did.

I'm also not sure how to go about testing - I confirmed that I can fetch queues and create new tasks manually, but I assume (looking at tests) that adding tests requires you to enable additional services on your test project?

In any case, would be glad to hear back from you. (On an unrelated note, fresh fetch of https://github.com/googleapis/googleapis is incredibly slow, I wonder if cargo has no optimizations for submodules and re-fetches it whole for each update of main repo)

Hirevo commented 4 years ago

Regarding the cloning speed, I can only agree with you, it is very painful.
It seems that the googleapis/googleapis's latest revision isn't large at all on its own, it's probably due to a very large Git history (very large diffs) or large files having been pushed in that repository and then removed at some later point but now saved in their .git.
We should most-likely consider vendoring the protobuf files directly (along with their license notice, of course).

msdinit commented 4 years ago

Thanks for the review! I renamed the method as you suggested, and added 2 new ones - get_task on Queue object and delete_task on the Task object, mainly for testing.

I also added an example test in tests/task.rs, but commented it out for now, so you could enable it when you see fit. I think the most common use-case for Tasks is to create a task and not do with it anything else, but I added the get and delete for ease of testing - creating a task and not deleting it wouldn't be ideal :smile: . The service account would require roles/cloudtasks.admin role for this. Allowing service account access only to a single queue (as opposed to all queues in the project) isn't well-described anywhere, so I include a command I use just in case you need it (queue can be created from console)

gcloud tasks queues add-iam-policy-binding projects/{project-name}/locations/{location-id}/queues/{queue-name} --member serviceAccount:{service-account-email} --role roles/cloudtasks.admin