adding a proxy setup to base conftest. just need to disable it when p…

[scbedd]

Resolves #25225, in addition to sanitizing common culprits of credential leaks:

• Shared secret environment variables (AZURE_X)
• Library-specific secret environment variables (SERVICE_X)
• Authentication requests

[mccoyp]

Hmm, I'll have to think about it. If it's something we'd want to be done whenever the test proxy is invoked, it might make sense to add it to the test proxy startup since I'm not sure if it otherwise has significantly more value in conftest.py. The new recorded_test fixture is still dependent on the test_proxy fixture, so putting this code in test_proxy would still cover the second round of migrations.

The main issue with this, I would think, is that most tests aren't using AZURE_CLIENT_X environment variables directly, but rather {DIRECTORY}_CLIENT_X. The former variables get assigned to the latter's values when the EnvironmentVariableLoader is invoked, but at test startup this wouldn't be sanitizing the correct values. If we sanitize service principal information in the EnviornmentVariableLoader, though -- like we do for explicitly requested variables -- then I think this plus that would cover our bases.

[scbedd]

The main issue with this, I would think, is that most tests aren't using AZURE_CLIENT_X environment variables directly, but rather {DIRECTORY}_CLIENT_X/

Dead on. BUT we could absolutely add these by default. Try to set up a few base ones that always get removed if not using PowerShellPreparer, etc.

Your suggestion to move this into the test proxy startup is well taken. I'll make that code change here.

[check-enforcer]

This pull request is protected by Check Enforcer.

What is Check Enforcer?

Check Enforcer helps ensure all pull requests are covered by at least one check-run (typically an Azure Pipeline). When all check-runs associated with this pull request pass then Check Enforcer itself will pass.

Why am I getting this message?

You are getting this message because Check Enforcer did not detect any check-runs being associated with this pull request within five minutes. This may indicate that your pull request is not covered by any pipelines and so Check Enforcer is correctly blocking the pull request being merged.

What should I do now?

If the check-enforcer check-run is not passing and all other check-runs associated with this PR are passing (excluding license-cla) then you could try telling Check Enforcer to evaluate your pull request again. You can do this by adding a comment to this pull request as follows:
/check-enforcer evaluate
Typically evaulation only takes a few seconds. If you know that your pull request is not covered by a pipeline and this is expected you can override Check Enforcer using the following command:
/check-enforcer override
Note that using the override command triggers alerts so that follow-up investigations can occur (PRs still need to be approved as normal).

What if I am onboarding a new service?

Often, new services do not have validation pipelines associated with them, in order to bootstrap pipelines for a new service, you can issue the following command as a pull request comment:
/azp run prepare-pipelines
This will run a pipeline that analyzes the source tree and creates the pipelines necessary to build and validate your pull request. Once the pipeline has been created you can trigger the pipeline using the following comment:
/azp run python - [service] - ci

[scbedd]

Not certain it's intended. But when we start up the test-proxy, we set a couple default custom items.

Then after reset, we don't actually resend those. I've moved all of the common default to _send_reset and then just called that during proxy startup.

One place, all the defaults. I could be missing reasoning here though 👍

[mccoyp]

Only setting the header rules once was actually intentional, albeit for rare edge cases. There are some teams that need request ID headers for tests, so being able to reset everything to a clean slate seemed like a good solution at the time.

I'd like to do something similar to your suggestion, so that we have a persistent default baseline of things to ignore -- otherwise, "resetting to default" isn't really giving people the default they're expecting.

To solve both those problems, it seems like the solution might be to provide methods for removing headers from this exclusion list 🤔

[ghost]

Hi @scbedd. Thank you for your interest in helping to improve the Azure SDK experience and for your contribution. We've noticed that there hasn't been recent engagement on this pull request. If this is still an active work stream, please let us know by pushing some changes or leaving a comment. Otherwise, we'll close this out in 7 days.

[ghost]

Hi @scbedd. Thank you for your interest in helping to improve the Azure SDK experience and for your contribution. We've noticed that there hasn't been recent engagement on this pull request. If this is still an active work stream, please let us know by pushing some changes or leaving a comment. Otherwise, we'll close this out in 7 days.