[GCSS] TFE fails when repo is transferred out of GCSS managed GHEC org

[pavlovic-ivan]

Description

When a repo is transferred out of a GitHub organization managed by GCSS, but the YAML configuration for that repo remains in GCSS, GCSS PRs fail

Context

This issue arose during a repository transfer where:

1. A project was developed internally
2. An OSDR was approved and the project transferred to a GCSS managed org
3. An open source community agreed to take ownership of the project (and repo) while we remain as maintainers
4. The repository was transferred out of our GCSS managed org
5. The YAML config remained in GCSS, causing TFE to fail

Impact

• Immediate: All new/upcoming PRs cannot go through successfully after the repository transfer
• Scope: This is a use case we expect to see again as we contribute projects to upstream communities

Expected Use Case

This represents a legitimate and repeating workflow:

1. Company develops something internally
2. Project is a good fit for an existing upstream project or community
3. Upstream project agrees to take ownership
4. Original developers remain as maintainers
5. Repository ownership is transferred

Current Behavior

When a repo is transferred out but its YAML config remains in GCSS:

• TFE fails to execute
• PRs cannot be processed
• System enters a broken state

Questions

What is the correct procedure when transferring a repository out of the organization?
What is the correct procedure when deleting or archiving a repository out of the organization?
Should the YAML config be deleted before or after the transfer?
What happens if we simply delete the config file from GCSS? Will Terraform fail due to how it tracks state?

[pavlovic-ivan]

Regarding the issue itself, or to be more precise, about this use case that surfaced:

• removing the repo's yaml file from GCSS needs to happen, however, this tells terraform to destroy a resource that doesn't exist anymore - so removing the file is necessary, but we need to think how and which instruction to give terraform
• next, there are terraform resources in the remote terraform state that need to be removed. for fixing the current issue, i've attached to the remote state, identified the resources to delete, and then deleted them manually with terraform state rm <resource address> command

Exact steps were:

• Login to app.terraform.io
• Open general settings of our VCS gcss GR workspace
• Change terraform execution from "remote" to "local"
• On my machine, checkout prod branch of GCSS repo
• Add empty cloud block to terraform backend
• Export two env variables TF_CLOUD_ORGANIZATION and TF_WORKSPACE
• Run terraform login
• Run terraform init
• Run terraform state list | wc -l to compare if the number of resources is the same as reported on app.terraform.io
• Run terraform state list | grep "Pulp-manager" to identify the necessary resources
• Iterate over the list of identified resources and running terraform state rm <resource address> for each

Clean up:

• Login to app.terraform.io
• In our VCS GCSS workspace general settings revert execution mode from local to remote
• Run terraform plan to verify all is good
• Locally unset the env vars
• Locally git reset --hard and change branches

[pavlovic-ivan]

For running terraform plan this is needed as well:

• Copy over app-list.yaml and import-config.yaml to feature/github-repo-provisioning dir
• In gcss_config dir create a subdir repos and copy over yaml repo config files
• In feature/github-repo-provisioning dir add terraform.tfvars file with app_id, app_installation_id, app_private_key, owner, and environment_directory vars set. Make sure to use EOT heredoc when setting app_private_key value.