* lll
* sss
* oipio
* vcvc
* enable test proxy start at test suite start for KV and storage , example created for attestation, we cannot find the base definitions for the test suites,
* Contrib
* clangs
* clangs
* test logs
* pipeline
* more clangs
* pipeline
* clang
* try try again
* try try again
* try again
* try again
* again
* update paths , moved to macro , call macro in target code
* core
* capitalization
* Compilation fixes for UWP
* More accurate condition
* Fix warnings
* Format files as vcpkg formats them; pull one change back from vcpkg
---------
Co-authored-by: Anton Kolesnyk <antkmsft@users.noreply.github.com>
- Made Context immutable (including marking the static ApplicationContext as const
- Put back TelemetryPolicy in all pipeline cases and removed User-Agent generation from RequestActivityPolicy (note: This part of the change may end up being reverted). Also updated parameters for TelemetryPolicy to make it clearer that the parameter is a package name, not a service name.
- Changed Az.Namespace value from being the package name to being the service name.
- Change test SpanExporter to fully capture exported values rather than keeping references to the values.
Co-authored-by: Anton Kolesnyk <41349689+antkmsft@users.noreply.github.com>
* Create ApiViewSettings for most existing packages
* Corrected name for blobs storage review name
* Added cspell settings for DCURL
* Create ApiViewSettings for most existing packages
* Corrected name for blobs storage review name
* Added cspell settings for DCURL
* ApiView settings changes for DataLake
* Renamed includeInternal to allowInternal; Added storage common; Fixed package names
* Fixed spelling error
* If there's an error accessing the site with no CRL checks, don't try it any more
* Stop checking example.com because it doesn't work
* Update sdk/attestation/azure-security-attestation/inc/ApiViewSettings.json
Co-authored-by: Ahson Khan <ahkha@microsoft.com>
* Update sdk/core/azure-core/inc/ApiViewSettings.json
Co-authored-by: Ahson Khan <ahkha@microsoft.com>
* Update sdk/keyvault/azure-security-keyvault-secrets/inc/ApiViewSettings.json
Co-authored-by: Ahson Khan <ahkha@microsoft.com>
Co-authored-by: Ahson Khan <ahkha@microsoft.com>
Jeff has pointed out that the current practice in the SDK of having a ServiceVersion which contains the current API versions of the service (for instance:
```c++
class ServiceVersion final {
public:
explicit ServiceVersion(std::string version) : m_version(std::move(version)) {}
AZ_STORAGE_QUEUES_DLLEXPORT const static ServiceVersion V2018_03_28;
AZ_STORAGE_QUEUES_DLLEXPORT const static ServiceVersion V2020_10_01;
};
)
```
Has a problem because the `ServiceVersion` construct has an implication that each of the `ServiceVersion` values listed is fully supported by the SDK.
The reality is that the SDK client team only tests the most recent API version listed in the SDK (the value which is the default version listed in the `ServiceClient` constructor).
How do we resolve this issue?
There are a few possible solutions that we’ve explored:
1) Test all the API versions listed in the `ServiceVersion` enumeration.
2) Remove the unsupported values from the `ServiceVersion` enumeration.
3) Remove the `ServiceVersion` enumeration
4) Remove the ability to set the API version at all.
Each of these solutions has some fairly significant drawbacks.
1) Test all the API versions listed.
The core problem with this is that the SDK team is small and adding tests to support every possible API version is going to be prohibitively expensive.
2) Remove the unsupported values from the `ServiceVersion` enumeration.
This is a breaking change and it means that moving to a new API version requires a breaking change to the SDK, even if the changes between API versions is strictly additive.
3) Remove the ServiceVersion enumeration.
This is also a breaking change for shipping SDKs (specifically KeyVault and Storage Queues). However, it is a one-time breaking change and we don’t have evidence of customers actually using the feature.
4) Remove the ability to set the API version at all.
Having *some* mechanism to set the API version is an important “escape hatch” which will allow customers to specify a specific API version even if that API version is not fully supported.
After discussing this a LOT, [@Ahson Khan](mailto:ahkha@microsoft.com), [@Rick Winter](mailto:Rick.Winter@microsoft.com), [@Jeffrey Richter](mailto:jeffreyr@microsoft.com), [@George Arama](mailto:George.Arama@microsoft.com), and [@Larry Osterman](mailto:Larry.Osterman@microsoft.com) came to the conclusion that we should probably take option #3, but leave the ClientOptions.Version value as a std::string.
* Implement tracing for Attestation and Template services
* Pipeline no longer requires service name if opting into distributed tracing; enable tracing in attestation service
* Generate user-agent header from request activity policy
* Added test to catch the redacted header regression
* Updated documentation to reflect API surface changes
* Prepare attestation for release
* removed references to RetrieveResponseValidationCollateral from docs
* Added C++ SDK team as owners of attestation SDK
* Added Ahmad from attestation team to attestation owners
* Removed dead API; switched attestation back to beta-3
* Split out attestation client factory into separate class
* Updated readme; clang-format
* Final set of API review changes
* Replaced () constructors with {} constructors
* binary cache and manifest
* update packages
* udpate
* add cache to private pipeline
* next try
* aver
* other
* again
* aver quick
* more
* this way
* again
* one more
* print
* test
* use depend
* more deps
* dep
* Apply suggestions from code review
Co-authored-by: Daniel Jurek <djurek@microsoft.com>
* updated to use group variable
* update identity
* end line
* Update vcpkg.json
* Apply suggestions from code review
* cspell
* remove comment
* updates
* make cache mode depend on SAS env var
* map env var only for internal pipelines
* other approach
* what about this
* and this
* try
* amd
* another
* extra step
* typo
* override for internal
* use default succeded
* azure core update manifest
* a
* run cmake-generate nightly as well
* check for SAS
* check cache
* no secret
* fix is secret
* pass explicit
* use secret all the time
* char
* One more
* export
* echos
* last
* array
* remove question
* ok
* weird
* use account key
* substring
* VCPKG_BINARY_SOURCES
* Add module installation
* task:
* Correct pathing for module
* update source gen
* format
* update spelling
* IsWindoows
* Use pwsh
* Cannot clobber with PSModule-Helpers. Attempt plain install
* Attempt plain install
* Revert unnecessary change to Update-DocsMsToc.ps1
* template ready
* curl is required on Windows as well for some CI gates
* attestation
* fix format
Co-authored-by: Daniel Jurek <djurek@microsoft.com>
* Moved samples around to meet new recommendations; added a couple of additional tests.
* Reworked attestation to include RetrieveAttestationValidationCollateral
* Attestation sample readme updates
* TPM doesn't need to retrieve response validation collateral
* Added cautionary warning about the dangers of overriding the TearDown method from inside a test case
* Added attestation team members to codeowners for attestation SDK
* Remove CODEOWNERS from cspell checks
* Don't hold a lock across retrieving the signers over the network
* Updated snippets in readme; clang-format
* changes
* vs generator
* use macro
* release and samples
* add target to build smoke test
* revert
* reuse macro for samples
* extra legs for samples only
* storage connection string
* format
* order and macro
* update
* samples
* missing
* Added GetPolicyManagementCertificates
* Added Add and Remove policy certificate
* Added support for Tpm attestation
* Moved TPM to attestation service specific section
* Added support for validation callback
* Updated RequestFailedException documentation
* Created extendableenumeration class
* Convert attestation to use extendable enumeration; added test for extendable enumerations
Co-authored-by: Casey Carter <cartec69@gmail.com>
