Allow duplicate file names in project hierarchy

[robrankin]

The Project Factory module doesn't allow duplicate filenames in the project hierarchy folder structure, as the filenames are currently used as keys in TF maps, and duplicates lead to duplicate key errors.

This change moves to building the map keys from either:

• The full path + filename with the separator of / replaced with - (in the abscence of an explicit name: key in the yaml)
• The name: key explicitly set in the project yaml definition file.

I've included two example project files, both named ce-0.yaml, but in different parts of the project hierarchy.

The first file, team-a/dev/ce-0.yaml has an explicitly set name: key, and produces the following resource:

  # module.projects.module.projects["ta-d-ce-0"].google_project.project[0] will be created
  + resource "google_project" "project" {
      + name                = "main-ta-d-ce-0"
      + project_id          = "main-ta-d-ce-0"
    }

The second file, team-b/dev/ce-0.yaml does not have an explicitly set name: key, and produces the following resource with the project name, ID and TF map key built from the path + filename:

  # module.projects.module.projects["team-b-dev-ce-0"].google_project.project[0] will be created
  + resource "google_project" "project" {
      + name                = "main-team-b-dev-ce-0"
      + project_id          = "main-team-b-dev-ce-0"
    }

---

Checklist

If applicable, I acknowledge that I have:

• Read the contributing guide
• Ran terraform fmt on all modified files
• Regenerated the relevant README.md files using tools/tfdoc.py
• Made sure all relevant tests pass

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[juliocc]

Not a bad idea but if we do this for PF we should probably do it for all other factories too.

I actually like the idea and the fix is fairly simple.

@ludoo wdyt?

[ludoo]

Forgot to send comments lol

[ludoo]

I prefer having the / being part of the key, to make it clear which part is the hierarchy and which is the project. Keep in mind the primary use case is using the key in substitutions (e.g. automation.project = "foo/bar"). Let's keep the path intact, and then find a way to map that to project ids. Probably by moving the replace there.

[ludoo]

Can you comment on this?

[juliocc]

the problem (I think) is that '/' is invalid in project ids

[ludoo]

We need to keep the path for keys, not project ids