### Packages impacted by this PR
@azure/identity
### Issues associated with this PR
Contributes to #26434
### Describe the problem that is addressed by this PR
Adds AKS managed identity integration tests
### Packages impacted by this PR
- @azure/abort-controller
- @azure/core-auth
- @azure/core-client
- @azure-rest/core-client
- @azure/core-http-compat
- @azure/core-lro
- @azure/core-paging
- @azure/core-rest-pipeline
- @azure/core-sse
- @azure/core-tracing
- @azure/core-util
- @azure/core-xml
- @azure/logger
- @typespec/ts-http-runtime
### Issues associated with this PR
### Describe the problem that is addressed by this PR
This migrates the core packages from a hybrid of CJS and ESM to an ESM
solution using [`tshy`](https://github.com/isaacs/tshy). The core is now
ESM, implemented as a module, and projects using `tshy` to CommonJS and
ESM.
The ESM build targets we will target include:
- ESM (Node)
- Browser
- React-Native
- Bun
- Deno
This will allow each system to pick up the correct output instead of
picking the browser bundle which has happened in the past. Currently,
our bun and deno support is strictly through npm compatibility and we
are not forking logic at this point for those runtimes.
In order to support ESM, `sinon` does not allow for ESM module mocking,
so we looked for an alterative in `vitest`. This PR also migrates all
core packages stated above from Mocha/Chai for Node and Mocha/Chai/Karma
for the browser to using `vitest` for all tests. Currently, the system
builds a test bundle which targets the correct files such as those
targeted for the browser, eg `log-browser.mts` becomes `log.js` in the
compiled output.
### What are the possible designs available to address the problem? If
there are more than one possible design, why was the one in this PR
chosen?
### Are there test cases added in this PR? _(If not, why?)_
### Provide a list of related PRs _(if any)_
### Command used to generate this PR:**_(Applicable only to SDK release
request PRs)_
### Checklists
- [ ] Added impacted package name to the issue description
- [ ] Does this PR needs any fixes in the SDK Generator?** _(If so,
create an Issue in the
[Autorest/typescript](https://github.com/Azure/autorest.typescript)
repository and link it here)_
- [ ] Added a changelog (if necessary)
---------
Co-authored-by: Deyaaeldeen Almahallawi <dealmaha@microsoft.com>
Co-authored-by: Maor Leger <maorleger@users.noreply.github.com>
Co-authored-by: Jeremy Meng <jeremy.ymeng@gmail.com>
### Packages impacted by this PR
- communication-call-automation
### Issues associated with this PR
- StartRecording now accepts PauseOnStart.
### Describe the problem that is addressed by this PR
The pauseonstart call recording option was added using a new swagger
spec.
New swagger:
5b7321a923/specification/communication/data-plane/CallAutomation/preview/2023-01-15-preview/communicationservicescallautomation.json
### What are the possible designs available to address the problem? If
there are more than one possible design, why was the one in this PR
chosen?
### Are there test cases added in this PR? _(If not, why?)_
### Provide a list of related PRs _(if any)_
### Command used to generate this PR:**_(Applicable only to SDK release
request PRs)_
### Checklists
- [x] Added impacted package name to the issue description
- [ ] Does this PR needs any fixes in the SDK Generator?** _(If so,
create an Issue in the
[Autorest/typescript](https://github.com/Azure/autorest.typescript)
repository and link it here)_
- [x] Added a changelog (if necessary)
---------
Co-authored-by: Jeremy Meng <jeremy.ymeng@gmail.com>
### Packages impacted by this PR
- `@azure-tools/dev-tool`
### Description
This is a quality-of-life change which makes inspecting recordings
easier. With the new asset sync flow, recordings are no longer stored in
the repo with each package. If you want to look at your recordings for
some reason (e.g. after re-recording to make sure you aren't leaking any
secrets), it takes a few extra steps to find them: navigate to the repo
root, look at the `.breadcrumb` file in the `.assets` folder, and then
use that to find the location of the recordings corresponding to your
package.
This PR improves that process by creating a symbolic link to the
recordings from each package, restoring the original flow.
* updating create recording request
* first draft. need to integrate node tests and then reach out to harsha
* commiting prettier update
* repair ascension algo
* add initial assets.json. update gitignore.
* move textanalytics recordings. time to try the node tests!
* remaining recorder updates. properly setting the assets.json path now
* using a different version of the proxy to ensure that we include all the bugfixes from recently
* bunch of changes for RECORDING_ASSETS_PATH
* lint applied
* Update sdk/test-utils/recorder/src/utils/utils.ts
Co-authored-by: Timo van Veenendaal <timov@microsoft.com>
* Update sdk/test-utils/recorder/src/utils/createRecordingRequest.ts
Co-authored-by: Timo van Veenendaal <timov@microsoft.com>
* Update sdk/test-utils/recorder/src/utils/relativePathCalculator.browser.ts
Co-authored-by: Timo van Veenendaal <timov@microsoft.com>
* Update sdk/test-utils/recorder/src/utils/utils.ts
Co-authored-by: Timo van Veenendaal <timov@microsoft.com>
* Update sdk/test-utils/recorder/src/utils/utils.ts
* Update sdk/test-utils/recorder/src/utils/createRecordingRequest.ts
Co-authored-by: Timo van Veenendaal <timov@microsoft.com>
* repair imports
* linting commit
* resolve failing node tests
* handle undefined set in environment variable
* commit recordings update now that the source has been updated
* fix pipeline
* if (!fs.existsSync(assetsPath)) return undefined;
* format
* fix lint
* Some refactors; calculate assets path in browser using existing environment variable
* Re-add second environment variable
* undo assets changes
Co-authored-by: Timo van Veenendaal <timov@microsoft.com>
Co-authored-by: Harsha Nalluru <sanallur@microsoft.com>
* Add ToC Generation script and wire up to docindex.yml for testing
Add Docs-ToC.ps1
Remove eng/scripts/docs from .gitignore but keep filtering other docs/ folders
Also checkout packages-legacy.json in sparse checkout
Also check out docs-ref-mapping/
Use -toc-test branch for demo
Review feedback
Review feedback
Remove unnecessary comment
Undo working changes
Add extension point to update the ToC before output
Undo changes to demo set-daily-docs-branch-name.yml
Check for FileMetadata before accessing it
Add ability to artbitarily nest packages in the 'Other' service.
Add comments from review feedback
Add plugin nodes
* Revert unnecessary changes to eng/common
* Review feedback
* Remove automatic ToC generation from main
* Set-StrictMode
* Remove Release-DocsMsDocs.ps1
* Use original syntax
* [EventHubs] ignore the generated certs/ folder
It is re-generated in every build and used for mock-hub testing
* Revert "[EventHubs] ignore the generated certs/ folder"
This reverts commit 7fed0608fc.
* [engsys] ignore *.srl files
They are files created and used by OpenSSL.
## What
- Enable Node unit tests for KV administration package
- Align our KV test-resources ARM template with dotnet's
- Add Managed HSM to ARM template
- Add script to enable Managed HSM from dotnet's script
## Why
We have lots of changes we want to make, but tests weren't currently runnable.
Making the entire suite runnable seemed like something we'd want to do early
before making behavior changes. Unfortunately there are some service integration
issues we want to address before we can enable _all_ the tests so we decided to pend
the ones that need some extra TLC to get the suite running.
Aligning with dotnet on the ARM template allows us to easily add the Managed HSM
bits from them and helps standardize what our template looks like across repos.
Finally, Managed HSM support is coming, so we might as well get the deployment correct
now.
* Elaborate on smoke test initialize logic in docs and script. Update .gitignore.
* Clarify NODE_PATH variable setting when running smoke tests locally
* Move smoke test .gitignore entries to git root
This PR intends to add soft-record, a way to only record what hasn't changed.
To be able to check whether the tests have changed, we check whether a MD5 hash of the test function's source code has changed from the previous time a recording stored this MD5 to the current test execution.
Any new recording will store this MD5 into the recorded file. To only record the tests that have changed, the user must specify the environment variable TEST_MODE, with value "soft-record".
Fixes#5156