cloud-native-toolkit / software-everywhere

Automation modules to deploy IBM Software on IBM Cloud, AWS, and Azure
https://modules.cloudnativetoolkit.dev
Apache License 2.0
9 stars 9 forks source link

Destroy failing in automated test for gitops modules #566

Open triceam opened 1 year ago

triceam commented 1 year ago

I have several gitops modules where the deploy action is passing tests, but destroy is failing. Most of the destroy is fine, but it fails when deleting the git repo (gitea). I've tried using back-level versions of the cli-tools container image, gitops provider, and gitops and gitops-bootstrap modules, but nothing seems to have fixed the issue.

When it fails, the git repo is deleted successfully, but the provider/igc cli returns the following error message:

Error: -15T15:57:16.929Z [ERROR] provider.terraform-provider-gitops_v0.12.0: Error running command: exit status 1
: tf_req_id=a3de68ff-6ded-0b50-20cc-63549a6a0a93 tf_resource_type=gitops_repo tf_provider_addr=provider @module=provider tf_rpc=ApplyResourceChange @caller=terraform-provider-gitops/gitops/resource_gitops_repo.go:567 timestamp=2022-12-15T15:57:16.929Z
Error: -15T15:57:16.930Z [ERROR] provider.terraform-provider-gitops_v0.12.0: Command error log: Unable to identify Git host type: https://gitea-gitops-wazi-dev-spaces.wazi-devspaces-0ed2b1307d0ce0e0627ae949f443cd72-0000.us-east.containers.appdomain.cloud/gitea-admin/gitops-wazi-dev-spaces-ocp4_latest_wazi Error: Unable to identify Git host type: https://gitea-gitops-wazi-dev-spaces.wazi-devspaces-0ed2b1307d0ce0e0627ae949f443cd72-0000.us-east.containers.appdomain.cloud/gitea-admin/gitops-wazi-dev-spaces-ocp4_latest_wazi
    at /snapshot/ibm-garage-cloud-cli/node_modules/@cloudnativetoolkit/git-client/dist/lib/util.js:126:15
    at Generator.next (<anonymous>)
    at fulfilled (/snapshot/ibm-garage-cloud-cli/node_modules/tslib/tslib.js)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
: tf_rpc=ApplyResourceChange @caller=terraform-provider-gitops/gitops/resource_gitops_repo.go:568 tf_provider_addr=provider @module=provider tf_req_id=a3de68ff-6ded-0b50-20cc-63549a6a0a93 tf_resource_type=gitops_repo timestamp=2022-12-15T15:57:16.929Z

It almost looks like the provider is trying to apply changes to the repo after it has been deleted.

Here are two examples for newly-created modules (from the gitops module template) that both exhibit this behavior: