Bug when fetching revision in apigee_proxy and apigee_shared_flow resources.

[swapna0211950]

Hi @scastria , When revision is fetched from apigee_proxy or apigee_shared_flow like below it is not fetching the last deployed version to a specific env using terraform from statefile. Rather it is picking latest revision from Apigee of other environment which is not expected. I guess we need to change the way to are trying to fetch the revision for a specific environment we are trying to deploy.

And if a new revision was deployed to another env. Even if the those changes are not intended in this environment it is trying to change to latest revision. Please fix this issue.

resource "apigee_proxy" "MyProxy" { name = "MyProxy" bundle = "proxies/MyProxy/MyProxy.zip" bundle_hash = filebase64sha256("proxies/MyProxy/MyProxy.zip") } resource "apigee_proxy_deployment" "example" { proxy_name = apigee_proxy.MyProxy.name environment_name = "dev" revision = apigee_proxy.MyProxy.revision }

[swapna0211950]

@scastria we might have to include environment attribute in apigee_proxy and apigee_shared_flow to fetch the exact revision of a proxy of a particular env. Please share your thoughts.

[swapna0211950]

Hi @scastria , Any help in fixing this issue would be great. Kindly fix this asap as cicd pipeline not behaving as expected with respect to proxies and shared flows.

[scastria]

Sorry, I spent a long time trying to decide how to design the Apigee TF provider when it comes to proxies and proxy versions. I didn't want to complicate things by requiring the TF developer to have to manage revisions of proxies. Therefore, an apigee_proxy always represents the LATEST revision of a given proxy.

I am open to revisiting this decision, but I would like to see your thoughts on how a TF config would look like if the developer has to manage the proxy, the proxy bundle, the proxy revision, and the proxy deployment of a revision to an environment all separately. It seems complicated.

[scastria]

I copied this model from AWS lambda functions and the AWS TF provider. Even though lambda functions have versions, the TF provider does not expose versions and the lambda function resource always matches the LATEST version.

If your bundle hash does not change, then your apigee_proxy should remain pointing at the same version it was originally deployed with as remembered in the TF state file. Therefore, I don't see how your apigee_proxy resource could suddenly change its revision number even if a new revision was deployed in a different environment. But I guess it all depends on how your TF configs are structured.

Basically, this is a hard problem to solve so I am open for suggestions.