chore: Include producer example

[romanini-ciandt]

The goal of this PR is to introduce an end-to-end test on sharing data with partner automation by adding a usage example. CI will do the auto discover tests (see the run here).

[romanini-ciandt]

I added this hard-coded sample DEK in order to avoid adding a null resource with openssl rand command.
(.index at the end is to avoid errors on lint about whitespace at the end of the file - we can't add a whitespace in DEK)

[tdbhacks]

This all LGTM, thanks Leo! It does bring up an interesting conversation in my mind though, which is that we should formalize some sort of breaking change policy for the long term, right? It comes to mind as this change adds new input variables, or for other changes we might make in the future.

It's definitely not a concern now and not blocking this change by any means, this repo is still work-in-progress and we state so clearly in the main README, but more like food for thought. I think TF repos generally have a way of announcing something will change, and later change it in the next major version, right?

[romanini-ciandt]

@tdbhacks that is an excellent point!
Usually when the repo is linked with Cloud Foundation Toolkit, it is possible to add a bot to manage the release versions. (See an example in another Google repo)

I'll make a couple tests/researches in order to understand how exactly how the bot works, but what I know is that bot cut releases based on the PR's names. So if the PR has feat/fix/chore in the title, it is considered a minor change, so if the current version is v0.1 it would cut v0.2 when triggered. If it's !feat/!fix (! announces breaking changes) it cuts a major, like from v0.2 to v1.0

[apeabody]

@tdbhacks that is an excellent point! Usually when the repo is linked with Cloud Foundation Toolkit, it is possible to add a bot to manage the release versions. (See an example in another Google repo)

I'll make a couple tests/researches in order to understand how exactly how the bot works, but what I know is that bot cut releases based on the PR's names. So if the PR has feat/fix/chore in the title, it is considered a minor change, so if the current version is v0.1 it would cut v0.2 when triggered. If it's !feat/!fix (! announces breaking changes) it cuts a major, like from v0.2 to v1.0

Hi @romanini-ciandt - It is https://github.com/googleapis/release-please, here is a sample config for a pre-1.0 release: https://github.com/terraform-google-modules/terraform-google-module-template/blob/master/terraform-google-%7B%7Bcookiecutter.module_name%7D%7D/.github/release-please.yml

[romanini-ciandt]

@tdbhacks that is an excellent point! Usually when the repo is linked with Cloud Foundation Toolkit, it is possible to add a bot to manage the release versions. (See an example in another Google repo)
I'll make a couple tests/researches in order to understand how exactly how the bot works, but what I know is that bot cut releases based on the PR's names. So if the PR has feat/fix/chore in the title, it is considered a minor change, so if the current version is v0.1 it would cut v0.2 when triggered. If it's !feat/!fix (! announces breaking changes) it cuts a major, like from v0.2 to v1.0

Hi @romanini-ciandt - It is https://github.com/googleapis/release-please, here is a sample config for a pre-1.0 release: https://github.com/terraform-google-modules/terraform-google-module-template/blob/master/terraform-google-%7B%7Bcookiecutter.module_name%7D%7D/.github/release-please.yml

Great reference @apeabody! Thanks for that! I'll create a PR to introduce the release-please bot into this repo.