Project delete when using Config As Code

[nleach999]

Describe the problem

There are a few different workflows for dealing with branch deletion in relation to deleting projects. It works great as long as the project and team are known at the time of handling the event. When using Config As Code, this generally doesn't work so well due to the CaC file getting deleted as part of the branch delete.

ADO has some limitations on how to handle deletion (e.g. it requires the delete to be part of a PR), and GitHub has an option that will look for it in the default branch. The problem is that the solutions require a default branch to be set in the YAML. If using Config As Code, it is not always going to be the case that a default branch is set if the deployment does it per-repository in Config As Code.

It is also not clear what happens when there is more than one default branch defined in the YAML. It is also not clear what would happen if the project name found in a default branch's CaC used an explicit branch name rather than a variable substitution (e.g. TEAM-project-master rather than TEAM-project-${branch} would potentially delete TEAM-project-master).

Proposed solution

Follow an algorithm across all SCM implementations for deletion:

1. Attempt to resolve team/project name based on the local YAML config (local team, and the project name is either the default format or set based on scripting). If no project is found, continue to step 2.
2. Attempt to retrieve config-as-code from each default branch until one matches. Build full project path from CaC team + project name overrides. If no project is found, continue to step 3.
3. Talk to the SCM API and try to retrieve CaC files from parent branches (as determined by the branch tree details retrieved via the SCM API) up to a configured limited set of levels above the deleted branch. (Default to 1...usually this would be enough.) Attempt to retrieve CaC and form the full project from CaC team + project name overrides found in the parent branch.

Additional details

If there are SCM implementations that make some parts of this infeasible, that would be simply a limitation of that SCM's workflow.