Skip to content

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

Merged
james00012 merged 4 commits intogruntwork-io:mainfrom
tjololo:feature/azure-container-apps-1491
Jan 6, 2025
Merged

feat(Azure): #1491 azure container apps support#1493
james00012 merged 4 commits intogruntwork-io:mainfrom
tjololo:feature/azure-container-apps-1491

Conversation

@tjololo
Copy link
Copy Markdown
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
Copy Markdown
Contributor

@james00012 james00012 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.


func getClientCloudConfig() (cloud.Configuration, error) {
envName := getDefaultEnvironmentName()
switch strings.ToUpper(envName) {
Copy link
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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)
@james00012 james00012 self-assigned this Jan 1, 2025
@james00012
Copy link
Copy Markdown
Contributor

Friendly ping on the comment above @tjololo

Copy link
Copy Markdown
Contributor

@james00012 james00012 left a comment

Choose a reason for hiding this comment

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

LGTM

@james00012
Copy link
Copy Markdown
Contributor

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

Copy link
Copy Markdown
Contributor

@james00012 james00012 left a comment

Choose a reason for hiding this comment

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

LGTM

@james00012 james00012 merged commit 7f6d2ae into gruntwork-io:main Jan 6, 2025
@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