Add submodule that automatically cleans up old projects

[Jberlinsky]

This pull request depends on #2

Adds an example tool that automatically cleans up old projects in a GCP Organization. This tool checks an organization for projects over a certain number of hours old, whose labels contain a specified key-value pair. All of these parameters are configured via environment variables passed to the cloud function. The nascent purpose of this tool is to clean up projects in the CFT continuous automation pipeline that linger as a result of CI failures or other errors.

This example is notably not currently controlled by an integration test. This is a potential future improvement.

[aaron-lane]

Please rebase the branch.

[ogreface]

I'm a little weary of putting an example with substantial side effects into a public repo that if run by default would delete old projects in the org. Mostly because I think it's a pretty unexpected result of a example for scheduled functions themselves.

[morgante]

The point of examples is to show what you could do, nobody should be blindly running examples.

This might be better off as a submodule though.

[ogreface]

Agreed on not blindly running examples. But we have modules where integration tests run all the examples. And while we'd desire the cleanup, someone using the module themselves wouldn't expect deletion just running the example (or eventually integration tests).

Could even gate it with a flag "actually_delete_projects" that defaults to false or something would be a little safer. Though I think the submodule might be the better choice as you said.

[morgante]

But we have modules where integration tests run all the examples.

That doesn't mean we always want to, but we could easily adjust the defaults to target projects we do want deleted.

We don't have anything which automatically runs all examples, nor should we.

And while we'd desire the cleanup, someone using the module themselves wouldn't expect deletion just running the example (or eventually integration tests).

I disagree. If you run an example called "delete projects" and are surprised when projects get deleted, that's WAI.

Could even gate it with a flag "actually_delete_projects" that defaults to false or something would be a little safer.

I'd rather not introduce flags which no actual user will ever need.

[ogreface]

But we have modules where integration tests run all the examples.

That doesn't mean we always want to, but we could easily adjust the defaults to target projects we do want deleted.

We don't have anything which automatically runs all examples, nor should we.

Ah, then I misunderstand that then. I thought we'd be making this part of the integration tests, as we've done on other projects. If that isn't happening, then it's less risky.

Possibly we want to rename cleanup -> deletion then.

Rebased!

[aaron-lane]

Based on out of band discussion, let's change this to be a submodule.

[aaron-lane]

The submodules directory must be renamed to modules (as unintuitive as it is).

[Jberlinsky]

@aaron-lane This is ready for another pass, thanks!

[Jberlinsky]

@aaron-lane Sorry for the delay in responding to these -- it appears that my Github notifications weren't quite tuned right. This is ready for another pass at your convenience.

[aaron-lane]

Thanks @Jberlinsky!