Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(Azure): #1491 azure container apps support #1493

Merged

Conversation

tjololo
Copy link
Contributor

@tjololo tjololo commented Dec 19, 2024

Description

Add support for asserting and getting azure container apps. Added tests and examples

Fixes #1491

TODOs

Read the Gruntwork contribution guidelines.

  • Update the docs.
  • Run the relevant tests successfully, including pre-commit checks.
  • Ensure any 3rd party code adheres with our license policy or delete this line if its not applicable.
  • Include release notes. If this PR is backward incompatible, include a migration guide.
  • Make a plan for release of the functionality in this PR. If it delivers value to an end user, you are responsible for ensuring it is released promptly, and correctly. If you are not a maintainer, you are responsible for finding a maintainer to do this for you.

Release Notes (draft)

Added support for azure container apps related get and assertion

Migration Guide

@tjololo tjololo requested a review from denis256 as a code owner December 19, 2024 12:57
@tjololo tjololo changed the title feat(1491): azure container apps feat(Azure): #1491 azure container apps support Dec 20, 2024
tjololo and others added 2 commits December 20, 2024 11:42
Add support for asserting and getting azure container apps. Added tests and examples
@tjololo tjololo force-pushed the feature/azure-container-apps-1491 branch from 6b4dd58 to a8366d7 Compare December 20, 2024 10:42
Copy link
Contributor

@james03160927 james03160927 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will also trigger test pipeline to see if it all passes.

test/azure/terraform_azure_container_apps_example_test.go Outdated Show resolved Hide resolved
modules/azure/client_factory.go Show resolved Hide resolved
modules/azure/client_factory.go Outdated Show resolved Hide resolved

func getClientCloudConfig() (cloud.Configuration, error) {
envName := getDefaultEnvironmentName()
switch strings.ToUpper(envName) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if the envName doesn't match any known environment, it returns an error. You could consider logging the defaulting behavior or providing guidance on what values are expected.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could find any good examples on how logging is done without having the testing.T at hand with terratest.modules.logger. Do you have any preferences or is it sufficient to just add enough context to the error returned?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm can you just pass in the testing.T variable along and share the context that weay?

Copy link
Contributor Author

@tjololo tjololo Jan 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That would require all the funtions XxxxE like ManagedEnvironmentExistsE to break the pattern from all other azure test functions and have t testing.T as an argument. My initial thought behind just erroring out is that the value defaults to AzurePublicCloud and if the user has set the env var to a invalid value the test should fail fast and return an error with the reason. This behavior also seems to follow the same pattern as the getEnvironmentEndpointE function. If my concerns around the different function pattern and fail fast with error is wrong I'm more than happy to make those changes

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a valid point. We could look into better logging pattern in a separate issue.

* remove unknown comments
* handle error from getTargetAzureSubscription
* improve error text if cloud env value not known (until preferred logging solution)
@james03160927 james03160927 self-assigned this Jan 1, 2025
@james03160927
Copy link
Contributor

Friendly ping on the comment above @tjololo

Copy link
Contributor

@james03160927 james03160927 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@james03160927
Copy link
Contributor

You would have to click the "update branch" before merging

Copy link
Contributor

@james03160927 james03160927 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@james03160927 james03160927 merged commit 7f6d2ae into gruntwork-io:main Jan 6, 2025
2 checks passed
@tjololo tjololo deleted the feature/azure-container-apps-1491 branch January 7, 2025 06:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Azure: Support for Azure Container Apps
2 participants