feat(functionsv2): Add sample for Audit Logs

[muncus]

Sample function prints fields to the logs, and has been manually tested with GCS write audit logs.

This is the Go version of this canonical sample: https://github.com/GoogleCloudPlatform/nodejs-docs-samples/blob/2991f86146742d00725c4dd73bf3719bd25e809b/functions/v2/index.js#L65

[snippet-bot]

Here is the summary of changes.

You are about to add 1 region tag.

• functions/functionsv2/helloauditlog/hello_auditlog.go:15, tag functions_log_cloudevent

---

This comment is generated by snippet-bot.
If you find problems with this result, please file an issue at:
https://github.com/googleapis/repo-automation-bots/issues.
To update this comment, add snippet-bot:force-run label or use the checkbox below:

• Refresh this comment

[grayside]

This is a very good sample PR, thank you. I can tell a lot of care was taken to track existing practices & patterns.

Unfortunately the google-cloudevents-go library is not recommended for use, we need to try another way. You can see in https://github.com/GoogleCloudPlatform/golang-samples/blob/main/functions/functionsv2/hellopubsub/hello_pubsub_test.go we created an ad hoc struct. We hope to switch to that library in the future.

[grayside]

blocking: Unfortunately this library is not GA and we shouldn't use it yet. I'm curious how you found your way to this library, and what we might do to prevent others for deciding to use it?

[muncus]

Thanks for bringing this to my attention. I've removed use of this library in favor of some minimal structs.

As for finding the library:
There is a documentation page that appears to conflate the two things called "cloud event": https://cloud.google.com/eventarc/docs/cloudevents#open-source
there are additional references in the Common Events section that link to protobufs, and the google-cloudevents repo docs.

[grayside]

suggestion: name declarations for longer struct definitions improve readability. I went looking for whether we have a standard on this, and I couldn't find one so it may just be opinion ;)

Since I'm curious if I'm missing something, @codyoss do you know?
I skimmed through https://golang.org/doc/effective_go and https://github.com/golang/go/wiki/CodeReviewComments

[muncus]

convention or not, i'm happy to add that. it seems like a reasonable practice, even if it is not standard. (will leave comment open for cody's input).

[muncus]

I think i've addressed your comments, and this is ready for another round of review.
(some comments left open for your input, feel free to resolve if you're satisfied).

[ace-n]

@tbpg can you rubber-stamp this? (I don't think @grayside is an admin. 🤷 )

[codyoss]

Should we me making use of generated proto stubs? https://github.com/googleapis/go-genproto/blob/4c6863e31247658eee07a5b0075340c04399d1d4/googleapis/cloud/audit/audit_log.pb.go#L43

Or does this even lib not work with those types?

[grayside]

Hey Cody, we're following a medium-term pattern of inlining the data structure. We're doing this both as a bridge to the future library dependency we plan to take (from https://github.com/googleapis/google-cloudevents libraries) and to cover a gap in documentation that's still being resolved.

I'm not strongly opposed to go using that reference, if you feel it's a reasonable thing for developers to take direct dependency. It would be a difference for this sample vs. the other GCF v2 samples.

[codyoss]

The inline struct is fine by me, I just wanted to make sure this choice was intentional. Anyone that uses our client libraries would already have this dep in their tree.