- update `sinon` version to `^15.0.0`. The breaking changes does not
affect our usages.
- upgrade `@types/sinon` to `^10.0.0`. This reveals test issue where
mocked tokens are not compatible with `AccessToken`. This PR fixes the
tests too.
### Packages impacted by this PR
@azure/eventgrid
**API View To Approve**
https://apiview.dev/Assemblies/Review/0972d8e0f04346beb9caa64994e8499f/d4f74574fb3d4f219b1bb6ea3652c09f?diffRevisionId=1bcdb912a7f84f35aa7773f029f70761&doc=False&diffOnly=True
### Issues associated with this PR
NA
### Describe the problem that is addressed by this PR
The EventGrid Service Team has added 5 new events. The SDK must be
regenerated to include the code changes related to these 5 new events.
The SDK minor version has been updated.
### 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?
There are no specific/complex design scenarios for this task. It is a
straightforward regenerate and some standard changes to the custom layer
of the code.
### Are there test cases added in this PR? _(If not, why?)_
No. This item is standard and we need not add test cases for every new
events. The existing cases would be sufficient.
### Provide a list of related PRs _(if any)_
NA
### Command used to generate this PR:**_(Applicable only to SDK release
request PRs)_
`autorest --typescript swagger\README.md`
### 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)
@xirzec @ellismg @jeremymeng Please review and approve the PR.
@lmazuel FYI
### Packages impacted by this PR
@azure/eventgrid
### Issues associated with this PR
None
### Describe the problem that is addressed by this PR
Now new features/bug fixes are added to this PR. The previous release
4.11.1 added new system events to the SDK. Normally, we update the minor
version and not the patch version for such releases. But, since only the
patch version has been updated for that release, in order to maintain
consistency, on the release guidelines, I am updating the minor version
and releasing a new version of the SDK through this PR.
### 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?
No special design consideration.
### Are there test cases added in this PR? _(If not, why?)_
Very trivial update of Minor Version. No test cases are required.
### Provide a list of related PRs _(if any)_
None
### Command used to generate this PR:**_(Applicable only to SDK release
request PRs)_
None
### 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)
@xirzec Please review and approve. Thanks
### Packages impacted by this PR
@azure/eventgrid
### Issues associated with this PR
NA
### Describe the problem that is addressed by this PR
The EventGrid Service Team has added 20 new events. The SDK must be
regenerated to include the code changes related to these 20 new events.
The SDK version must be updated and a out-of-band release has been
planned for this service.
### 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?
There are no specific/complex design scenarios for this task. It is a
straightforward regenerate and some standard changes to the custom layer
of the code.
### Are there test cases added in this PR? _(If not, why?)_
No. This item is standard and we need not add test cases for every new
events. The existing cases would be sufficient.
### Provide a list of related PRs _(if any)_
NA
### Command used to generate this PR:**_(Applicable only to SDK release
request PRs)_
`autorest --typescript swagger\README.md`
### 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)
@xirzec @ellismg @jeremymeng Please review and approve the PR.
@lmazuel FYI
***NO_CI***
- `@rollup/plugin-commonjs` to `^24.0.0`
- `@rollup/plugin-json` to `^6.0.0`
- `@rollup/plugin-multi-entry` to `^6.0.0`
- `rollup-plugin-polyfill-node` to `^0.12.0`
- `@rollup/plugin-inject` to `^5.0.0`
- `@rollup/plugin-replace` to `^5.0.0`
Fix notification-hubs rollup test config: now sourcemaps plugin is complaining
about .ts file. Move typescript plugin before it.
Fix service-bus to include needed rollup dependencies. It was lucky to be able
to re-use on other packages to install them but is failing in some builds.
* [EventGrid] Update Healthcare Events, Prepare for Nov Release
The only updates for our November release are adding type interfaces
for two new healthcare API events which the service now sends.
* Add Dicom as an allowed word
***NO_CI***
- string replace in package json: 12 => 14 for engines/node and for dependency @types/node
- eslint: update `json-engine-is-present` rule to 14.0.0 as LTS version
- identity: react to typing improvements for `readFile()`'s `options.encoding`
- trivial generated api.md file changes due to @types/node version bump
***NO_CI***
This is a follow-up to PR #21536 and PR #21537.
- upgrade typescript to 4.6.0 for communication packages
- upgrade typescript to 4.6 for test-utils and dev-tool
- upgrade typescript to 4.6
The service now supports the "channel name" feature added in
4.10.0-beta.1 and this release adds support in a GA package.
There are no changes in the implementation from 4.10.0-beta.1
* release eventgrid package
* Fix test case failures
Co-authored-by: ZiWei Chen (WICRESOFT NORTH AMERICA LTD) <v-ziweichen@microsoft.com>
Co-authored-by: Mary Gao <yanmeigao1210@gmail.com>
The perf framework previously did not support true multi-core operation. This PR provides an implementation of multicore support based on a message-passing model.
Two new options are added to the perf framework as part of this PR:
* `--cpus`/`-c`: number specifying the number of cores (CPUs) to use. Defaults to 1, set to 0 to match the number of cores on the machine.
* `--use-worker-threads`: boolean, defaults to false. Pass this flag to use `worker_threads` instead of `child_process` for multithreading (see Multithreading implementations, below)
I recently improved the error messages coming out of the recorder in #21575, making the recorder client throw a special error when the recorder failed to find a matching recording for a request. Before that change, the recorder client would yield a standard RestError with a 404 response when a request couldn't be matched to a recording.
Event Grid has a few tests which expect a 404 response from the service. These tests catch and test for a RestError with 404 status to ensure that this response is received. However, during playback mode, the recorder was not finding a recording to match the request with, due to an issue with sanitization. Before my change to the error message, the tests were passing fine (incorrectly), since they were handling the 404 that was coming from the test proxy and not the recording itself. They're now failing since the error that's coming back is different.
The reason that the test proxy could not match the requests to a recording is because of some issues with sanitization of the recording. This change fixes the sanitization and gets the tests passing again, with the RestError now coming from the recording itself giving a 404 response, as was originally intended.
The EventGrid service team is adding a new feature called channels
which can be used by Partner Topics (note that "partners" here does
not mean internal Microsoft folks, but rather larger external
customers). The channels act as a sort of namespacing mechanism
(similar to the Domain Topics for topics using the classic
"EventGrid" schema) but are only supported when the schema of the
topic is set to Cloud Events.
Unlike domain topics, where the event payload includes information on
which topic inside the domain to send to, the channel which is
published to is specificed in an `aeg-channel-name` header as part of
the request to send events.
To support this - we add a new property to our options bag,
`channelName` which can be used to specify the channel to use when
sending a set of events. Because this feature is specific to Partner
Topics, we did not try to model it as another named parameter of the
`send` function or create a new method which would be specific to
channels. Most customers won't be using Partner Topics (although,
again, this is a feature that can and is used by external customers)
so we did not want to introduce a new cognitive burden.
We have authored our typescript typings for this function such that
the `channelName` property on the options bag only appears for clients
which are using the CloudEvent schema.
The service team has this feature in Preview today, so we'd like to
release a preview version of the library with support for this feature
that their customers can use. We've manually validated this against a
partner topic provided by the service team and are working on getting
automated tests that we can record.
### Packages impacted by this PR
event-grid
### Issues associated with this PR
Resolves#21249
### Describe the problem that is addressed by this PR
As part of a larger effort, this PR upgrades @azure/event-grid to core-tracing
1.0 now that it has GA'd.
### 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?
One open question was how should I test the
`cloudEventDistributedTracingEnricherPolicy` in this new world. We've done a lot
of work to abstract away from OTel and our test instrumenter no longer creates
headers to avoid polluting the recordings.
But since the policy depends on the traceparent headers to exist we needed to
execute that logic somehow. The solution I landed on is a custom pipeline policy
that puts the two headers this code depends on to exercise that code without
concerning itself with _how_ the headers get there.
This change updates our swagger to the latest version in
`azure-rest-api-specs`. This includes support for three new system
events related to healthcare.
- previously the runner load sample modules in main(). Any error would cause
main() to exit thus skipping rest of tests. Now the samples are loaded when they
are executed so errors in loading modules can be caught.
- the consumeEventsFromServiceBusQueue sample is calling `process.exit()` upon
completion, causing the runner to exit because it currently runs tests in-proc.
Update the test to exit with code 1 when failing.
In #20273 we moved our `@azure/core-client` reference to `^1.5.1` in
order to pick up some new features we needed for use with the new
recorder. The version of this package has not shipped yet and we'd
like to release EventGrid this release cycle.
Talking with Jose, there's nothing we should need right now newer than
1.5.0, so we'll move our constraint back to that version.
This change updates our Swagger API reference and re-runs the code
generation. There are no new events this sprint, however a new value
was added to and enum used by some `Microsoft.Media` events.
As part of the update, we pulled in changes around a new
`aeg-channel-name` header which was added to support a new Event Grid
feature. It is currently unexposed, but we expect to add support in
the April release.
This change pulls in the latest changes from the
`azure-rest-api-specs` repository for system events in Azure.
It fixes two issues with our typings for events (a property name was
incorrectly cased and another property was typed as a boolean when the
event delivered by the service uses a string (with the value of `true`
or `false`) instead of a boolean as might be expected.
This is a breaking change for code which is written in typescript and
which uses any of these impacted properties because the underlying
type has changed from string to something else. However, any code
which previously was written against the old typings would have
*failed* at runtime with a type error, so in practice anyone who gets
an issue is now correctly discovering a bug in their program at
compile time now instead of runtime.
Similar to #19862, we have recently started to see some issues in our
nightly min/max jobs that prevent us from saving the entire Response
object during the `onResponse` callback due to multiple imports of the
"same" type.
Similar to the resolution for #19862, I've decided to just not use
nominal types from `core-client` here and instead just stash away the
parts of the response I need inside the callback and observe the
values after.
Fixes#20014
**Checklists**
- [x] Added impacted package name to the issue description
**Packages impacted by this PR:**
@azure/event-grid, @azure/service-bus
**Describe the problem that is addressed by this PR:**
In order to conform to the OTel spec and allow for easier aggregations we
updated tracing policy to name the span `HTTP <method>` instead of `<path>`.
Unfortunately we missed a few tests, so this updates those tests to reflect the
core changes.
While editing these tests, I realized I never added CHANGELOG entries for the original
change. This PR addresses that as well.
**Provide a list of related PRs**_(if any)_
#19838Resolves#19887Resolves#19885
* [EventGrid] Event Schema Updates for January Release
This change pulls in the latest changes from the
`azure-rest-api-specs` repository for system events in Azure.
While no new events have been added with this release, some events now
have additional properties (the service teams which produce these
events now provide additional information in each event).
In addition, it fixes an issue we had with some of the Azure Resource
Manager events. We discovered that the event schemas for these events
was authored incorrectly and said some properties were of type
"string" instead of either a rich object or a map of strings to
strings.
A customer discovered this for .NET and that caused us to do some
investigation with the service team to discover that the specification
was wrong and get it corrected.
This is a breaking change for code which is written in typescript and
which uses any of these impacted properties because the underlying
type has changed from string to something else. However, any code
which previously was written against the old typings would have
*failed* at runtime with a type error, so in practice anyone who gets
an issue is now correctly discovering a bug in their program at
compile time now instead of runtime.
To prevent these issues in the future, we've been working closely with
the service team to introduce guard rails that ensure the events
services publish correspond to the schemas they have have published.
* [EventGrid] Prepare for Release
Solves: https://github.com/Azure/azure-sdk-for-js/issues/9329 for packages under `sdk/eventgrid/`.
Updated `prettier` dev-dependency version to latest `2.5.1`.
Files were re-formatted as well. There are only format changes in this PR, no manual changes except for package.json files.
Main format changes with Prettier 2.x in this PR include:
- Trailing commas by default.
- Whitespace added after every `function` keyword.
The cloud event distributed tracing enricher depends on `tracingPolicy` being
applied before it so it can copy the `traceparent` header that added by
`tracingPolicy` to its event payload. However, it doesn't specify this
dependency and relies on the implicit policy ordering when request pipeline is
created. This happened to work because `tracingPolicy` was not in a phase, and
was added before `cloudEventDistributedTracingEnricherPolicy` which is not in a
phase either. But after refactoring done in PR #19078, `tracingPolicy` is moved
to be after the Retry phase, which comes after policies that are not in a phase.
Now the `traceparent` has not been set when
`cloudEventDistributedTracingEnricherPolicy` is applied. This is not the
expected behavior and caused test failure.
This change fixes the issue by explicitly requiring the
`cloudEventDistributedTracingEnricherPolicy` to be applied after the
`tracingPolicy`.
* base code
* 'Retry-After',
'0',
manual replacements
* setDefaultRetryAfterIntervalInNockFixture
* setDefaultRetryAfterIntervalInNockFixture
* changelog
* changelog
* docs
* docs
* 19501
* Update sdk/test-utils/recorder/test/node/utils.spec.ts
* Format
* Update recordings to have retry-after value of 0
and remove some 202 responses
Co-authored-by: Jeremy Meng <yumeng@microsoft.com>
As discussed in #17076, we no longer have the need for the `docs` script in each of our packages. This PR removes this script and the related dev dependency on typedoc
This PR makes the following updates regarding the `nyc` dependency
- Update to v15 from v14 across all packages
- Updates to `@azure/monitor-opentelemetry-exporter` as it failed to run the tests with the updated nyc.
- Update the test scripts to use the js files in the dist-esm folder like all other packages instead of using the ts-node plugin.
- Update one of the tests for `@azure/monitor-opentelemetry-exporter` to use the right path for package.json file now that the tests are being run from the dist-esm folder.
Random set of live tests were triggered from this PR to ensure that nyc works as expected.
The failure for data-tables is an unrelated service side issue
Resolves#19232
## What
- Fix incorrect logic when suppressing chai's circular dependency warnings
- Move to the common dev-tool configuration where possible
## Why
This is a longstanding issue that we have, where an incorrect logic was copy-pasted to other places. I figured while cleaning this up that any package I touch can just convert over to the shared dev-tool configuration. Where I was unable
to do that, I just fixed this bug to avoid too many changes in one PR.
Fixes#14292Resolves#17818Resolves#17816Resolves#17815Resolves#17814Resolves#17813Resolves#17810
The CNCF moved some files around in their specs repository, which
broken this link. Use a versioned URL instead of pointing at their
main development branch so this doesn't happen again in the future.
Reported in #18033.
Basically did a bulk find+replace everywhere. Things _seem_ to be working OK, but wouldn't be surprised if there's something somewhere I've missed, or somewhere where I've replaced something I shouldn't.
I've split the rename of PerfStress -> Perf and runAsync -> run into two commits for ease of review :)
## What
- Update API Extractor to the latest version (currently 7.18.11)
- Regenerate all API reviews by building all the packages
## Why
This is something we keep bumping into. First, we needed to upgrade API Extractor to allow us to re-export directly from
`@opentelemetry/api`. Then, it looks like we needed this to upgrade TypeScript to 4.4.
We are way behind on this version, and it's time to upgrade.
## Callouts
How noisy is this?! Here's what's happening - somewhere around 7.9 I think API Extractor improved the way it detects name
collisions with predefined globals. Things like KeyType, Response, etc.
If there's a clash, the generated API markdown file will rename <Item> to <Item_2> to make the name collision explicit.
Talking to folks on the team, and the poor souls that will be doing API Review approvals, we agreed that doing the upgrade
in one fell swoop is the way to go.
Resolves#9410
* Adding a note in the readme to release publicly
* rename `@azure/test-utils-recorder` to `@azure-tools/test-recorder`
* lock file
* delete recorder new file
- Our convention now is to use `types`.
- Some packages output type definition files into `types` directory but the `clean` scripts still use `typings`.
This PR adds missing changelog entries for the times we
- updated tracing dependencies to use the GA version of OpenTelemetry
- updated to target ES2017
In #16700 we updated our tests to generate the key we used for testing
by doing a base64 conversion of a fixed string so we didn't have something that looked like a key embeded in source which was upsetting some static analysis tools.
This casues a build break in the min/max testing where `btoa` can't be found when building the test. Since we have the correct runtime behavior in the test to only call `btoa` when we are not in a node-context we simply reference the dom library to appease the compiler.
## What
- Remove `setTracer`
- Remove `NoOpTracer` and `NoOpSpan`
- Use Otel's APIs where possible (like when creating a no-op)
- Respect AZURE_TRACING_DISABLED environment variable
- Include test support for tracing utilizing OTel's trace API
- Avoid injecting invalid `tracerparent` header fields
## Why
- `setTracer` was added before OTel had their own implementation of a global tracer provider. For consistency with other libraries we should use the global tracer that was registered. It also leaves us out of the business of maintaining caches, global tracers, and other annoying things.
- These are no longer needed, since OTel has a recommended way to wrap a span in a NoOp. And, if no tracer provider was registered, a non-recording tracer (NoOp) will be created. All managed by OTel
- Finally, AZURE_TRACING_DISABLED is one of the env vars our guidelines say we should support
Resolves#16088Resolves#15730Resolves#10205
## What
- Move `TestTracer`, `TestSpan`, and `SpanGraph` from @azure/core-tracing to @azure/test-utils
## Why
1. Having a folder called src/**test**/ does not play nicely with defaults generated by tools such as Yarn (specifically Yarn autoclean)
2. These are test support interfaces, and shouldn't be part of our public API anyway - now that we have @azure/test-utils it's the more appropriate location for them
Resolves#16265Resolves#16201
Related #13367
* displayed links as a list rather than a single line
* appconfiguration\Readme: displayed links as a list rather than a single line
* confidential-ledger-rest/README.md: display links as list
* container-registry/README.md: display links as list
* cosmos/README.md: display links as list
* iot-device-update/README.md: display links as list
* eventgrid/README.md: display links as list
* event-hubs/README.md: display links as list
* eventhubs-checkpointstore-blob/README.md: display links as list
* formrecognizer/README.md: display links as list
* identity/README.md: display links as list
* iot-modelsrepository/README.md: display links as list
* keyvault-admin/README.md: display links as list
* keyvault-certificates/README.md: display links as list
* keyvault-keys/README.md: display links as list
* keyvault-secrets/README.md: display links as list
* ai-metrics-advisor/README.md: display links as list
* mixedreality-authentication/README.md: display links as list
* monitor-query/README.md: display links as list
* purview-catalog-rest/README.md: display links as list
* purview-scanning-rest/README.md: display links as list
* quantum-jobs/README.md: display links as list
* search-documents/README.md: display links as list
* schema-registry/README.md: display links as list
* schema-registry-avro/README.md: display links as list
* service-bus/README.md: display links as list
* storage/storage-blob/README.md: display links as list
* storage-blob-changefeed/README.md: display links as list
* storage-file-datalake/README.md: display links as list
* storage-file-share/README.md: display links as list
* storage-queue/README.md: display links as list
* data-tables/README.md: display links as list
* ai-text-analytics/README.md: display links as list
* video-analyzer-edge/README.md: display links as list
* web-pubsub/README.md: display links as list
* web-pubsub-express/README.md: display links as list
* core-lro/README.md: display links as list
* changed from the word master to main
* changed the word master to main
* another update to the final reandme to change the word master to main
* Update README.md
fixed a type in the link
* Update sdk/anomalydetector/ai-anomaly-detector/README.md
Co-authored-by: Deyaaeldeen Almahallawi <dealmaha@microsoft.com>
Co-authored-by: Deyaaeldeen Almahallawi <dealmaha@microsoft.com>
As part of the development of the new pipeline, event grid was hand
ported to use the new pipeline. Now that the code generator targets
the new pipeline, we can start using it to generate the code.
Since EventGrid includes the `/api/events` path segment in the
Endpoint, We need to do a small amount of post processing of the
generated code, to ensure `/api/events` is not appended to the
endpoint (we do this by setting an empty path in the operation spec,
which is as things were before moving over to the generator).
Fixes#15823
## What
- Update `@azure/core-rest-pipeline` to 1.1.0 from beta
- Update dependencies to the latest version
- Update everyone to the same version of `@azure/core-tracing`
## Why
Now that we used the CAE capabilities added in core-rest-pipeline in both container registry and key vault it's time to GA this version! It also unblocks our efforts to get everyone upgraded to the latest core-tracing (and OTel by extension) versions.
- Remove the "FarmBeats" system events (i.e. AgriFoodFarming). The
service team is unwilling to GA the shape of the events as this
time.
- Set release date in `CHANGELOG.md`
This change updates to the latest version of the EventGrid data plane
specification, and brings in some new event types (one for Storage and
a handful for FarmBeats).
In addition there is a small bugfix to one of the event names
(discovered as we move towards tooling the process that generates
these mappings) to use the correct name.
When events are sent using the Cloud Event schema, and distributed
tracing is used (so `traceparent` and `tracestate` are added as
headers on an http request) the SDK automatically ads this information
to the events as they are sent, using the distributed tracing
extension properties, as documented by the CNCF, if they are not
already present.
Add a small note about this to the README.md
Fixes#12036
This change splits our tests into two folders:
- `public` which only uses surface area exported by the package.
- `internal` which tests internal methods which we don't export from
the top level package.
This allows us to test the public surface area independently from the
private one, which is helpful for classes of testing.
Fixes#13813
This change moves our samples to be generated via `devtool`, as part
of the samples quality effort. Much of the diff here is just moving
code around to confirm to the new patterns, as outlined in the
migration guide, but one interesting outcome is that since the samples
are now part of the ts compliation for the package itself, and our
samples use service bus (which itself uses AsyncIterators) we have to
add a `lib` in our `tsconfig.json`.
We do not add any polyfill or anything like that to our `package.json`
because our implementation does not use these features.
After talking about this with will, I did manually patch the
*generated* tsconfig.json for our samples to say we target ES2018
(since the samples will need this), and he will add support for that
for the tool going forward.
In addition, we add some more resources to our `test-resources.json`
so that these samples can run in CI and be validated.
Fixes#14471Fixes#14573
`@azure/core-auth` added the `NamedKeyCredential` and `AzureNamedKeyCredential` symbols in version 1.3.0. Currently only `@azure/core-amqp` and `@azure/event-hubs` references these directly and need to be using 1.3.0, but updating in all packages that depend on it to satisfy rush.
* Upgrading to opentelemetry 1.0.0 (rc.0)
Did a few things that made this MUCH easier.
Now that everyone is using the createSpan from @azure/core-tracing we
no longer need _every_ project to reference opentelemetry/api! That has
been removed as part of this PR.
Unfortunately, the leaky nature of JS means that packages still need to
worry about opentelemetry when they build their browser bundle for
testing. To make that simpler I've added a common function to dev-tool
that everyone can call in their rollup that will give them the correct
named exports. This is hooked up for everyone at this point, so the next
time something like this happens I should be able to control it
centrally.
Now for the API breaking changes that I had to fix:
- CanonicalCode is gone and is replaced with SpanStatusCode.
SpanStatusCode has a much smaller set of codes (literally: ERROR, OK
or UNSET) so that simplified most of the way we were handling setting
a span status on error.
- There is a new field (`tracingContext`) that contains `Context`. You
now pass a context, not a span, to indicate what your "parent" is.
You'll see this where I've removed `SpanOptions.parentSpan`. Mostly
it's a simple replacement.
* [EventGrid] Fix ACS Event Names
The Azure Communication Services team noticed that some of their event
shapes were wrong and have [updated the
swagger](https://github.com/Azure/azure-rest-api-specs/pull/13485) to
address this.
This commit pulls these changes into our SDK.
Fixes#14345
* [EventGrid] Add types for RecordingFileStatusUpdated event
This is a new event ACS is sending.
* [EventGrid] Remove incorrect ACS System Events
After discussion, we are comfortable removing these two event names
from our mapping. The rationale here is that the service never sent
events using these names (they made a typo when documenting the event
names in Swagger) and so any code using them was going to be wrong. In
this case, we like that if you're using TypeScript you'll see a
compile time issue here because it will be pointing to place in your
code where things were never going to behave as you might have
expected.
The `CHANGELOG.md` has been updated to provide a little more
perscriptive guidence on what to do here, and we feel OK about not
doing a major version bump.
* [dev-tool] Experimental samples publish command
* Updated template samples structure
* First generation of template samples
* Update to ts-node 9 and use transpilation mode for speed.
* Many improvements and fixes.
- Fixed several bugs with generation.
- Added environment variable analysis.
- Refactored modules for code organization.
- Added azsdk- JSDoc tags for weighting and ignoring samples.
- Made almost all illogical situations yield errors instead of warnings.
* Rework text analytics
* Fixed a bug in the README template saying something about the Template package
* Regenerate text analytics samples
* Consistency changes to dev-tool/register
* Updated TA and Template package.json
* Fixed a couple of file name rendering bugs in the template
* Added API ref link override and regenerated Template samples
* Format
* Fix broken link
* Made typescript version reflect dev-tool ts dependency
* Revert weird change to cosmosdb package.json
* Alpha sort template deps
* Added MIN_SUPPORTED_NODE_VERSION
* Tweaked default tsconfig.
* Use version 1.0.0 instead of 0.1.0
* Pull sample generation info types into their own module.
* Added resource creation link generation.
* Regenerate template samples
* Regenerate text analytics samples
* Regenerate text analytics samples
* Regenerate template samples
* Fix bug in TA samples
# Problem
`no-invalid-this` makes sure uses of `this` are valid (see [docs](https://eslint.org/docs/rules/no-invalid-this) and [implementation](8984c91372/lib/rules/utils/ast-utils.js (L900))). However, uses of `this` are rampant in our test suites because this is how mocha unit tests are structured, the Mocha context can be accessed only through `this`.
# Fix
So instead of disabling `no-invalid-this` in our test suites, this PR tags functions that reference `this` with `@this` and that satisfies the rule requirements (see [docs](https://eslint.org/docs/rules/no-invalid-this)).
# Discussion
It could be argued that this work just replaces one comment annotation with another so we did not really solve the underlying problem. However, the inherent problem lies in how mocha itself works and there is nothing we can do other than probably migrating to another framework that is more sane/type-safe. One minor improvement we get is we now have slightly less syntactic overhead because we need to tag just the function instead of individual lines in its body that violate the rule.
# Trade-offs
Pros:
- function tags are less than line tags
Cons:
- whitelisting one more tag with the tsdoc linter that our devs need to learn about
- still having rampant tags everywhere
Fixes https://github.com/Azure/azure-sdk-for-js/issues/11404
I confirmed with the TypeScript team that patch releases should not introduce breaking changes. This PR uses tilde in TypeScript version we use so get the latest patch releases for v4.1.
* [EventGrid] Update to {core-client,core-rest-pipeline}@^1.0.0
* [EventGrid] Prepare for GA Release
- Update version to `4.0.0` from `3.0.0-preview.4`. The move to
`4.0.0` is to align our version with the new SDKs for EventGrid from
the other languages.
- Update CHANGELOG.md
Currently, `rush lint` fails for our perf tests, see https://dev.azure.com/azure-sdk/playground/_build/results?buildId=787394&view=logs&j=58292cae-3c74-5729-4cfd-9ceee65fe129&t=3f037b94-2b49-5715-3208-309f8588a4cd&l=441
This PR fixes this by doing the following:
- adding `eslint` as a dependency for those packages.
- updating the npm lint script to not use the `.eslintrc.json` at the root and use a newly added one instead that does not use our azure sdk plugin for eslint.
- fix linting issues if any and make the lint script fail in the future when linting errors happen.
In addition to those fixes, this PR fixes linting issues in container registry so `rush lint` runs successfully.
* [EventGrid] Regenerate Code
Re-run the code generation based on the latest README.md in the rest
specs repository. This picks up some changes to some Azure
Communication Services event types that the service has changed.
* [EventGrid] Updates for GA
Adopt feedback from architecture board review, the changes here are
focused on the consumption side:
- We decided that we did not want to apply AutoRest style mapping for
system event data payloads, instead we would keep the `data` value as
is. This allows us to remove a bunch of our custom logic around
invoking the mappers. One implication here is that we need to remove
the `format` directive for model types in our swagger before
generating code with auto-rest, so that the interfaces defined for
custom events use `string` as the type instead of `Date`.
- Some light renaming of interface names tied to System Event
Data. There was a common convention from some services to use a
`Properties` suffix in their schema name, which caused us to
generate interfaces with the suffix `Properties` which was not very
idiomatic.
- Mark properties in shapes from System Events as present, based on
the sample data that is published by the EventGrid service team on
docs.microsoft.com.
Fixes#10992
* [EventGrid] Add test to lock in endpoint behavior
We require that the user inclide the `/api/events` path as part of the
endpoint when creating a client. This is so that we remain flexable
and allow the event grid service to evolve the structure of their
endpoint URLs.
We already had this behavior, but so just add a test to lock the new
behavior in.
* [EventGrid] Update Recordings
* Revert "[core v2] prepare for GA release (#14170)"
This reverts commit 0e06e728d6.
* [Core v2] Revert GA version bump and release another preview
* Not releasing core-xml
* Update release date
Perf test projects for eventgrid and text-analytics are depending on a released version of the packages.
This PR updates it to depend on the versions on master instead.
* [core v2] prepare for GA release
- core-rest-pipeline. Update version and release date
* - core-xml. update version and release date
* - core-client. update version and release date
The EventGrid library is a fairly lightweight wrapper over the
service, but we would like to have a least one performance test so we
have a baseline to compare things with going forward.
This test just sends events using the CloudEvents schema to an
endpoint. This operation was chosen because it has the most work
being done by the SDK (there's a small level of translation that needs
to be done to adapt the user facing model to what the service expects
on the wire).
- Making some changes to simplify the "duplicate" models that we're exporting to mirror the opentelemetry models (addresses feedback from @xirzec and @bterlson)
- Switch core-tracing back to the `-preview` version naming style. Changing it mid-stream like we did breaks internal tooling.
Jeremy Meng
kazrael2119
Azure SDK Bot
Sarangan Rajamanickam
Jeremy Meng
Jeff Fisher
Matt Ellis
colawwj
Christian Baer
Timo van Veenendaal
praveenkuttappan
Maor Leger
Will Temple
Harsha Nalluru
Jonathan Cárdenas
Ramya Rao
Timo van Veenendaal
Jiao Di (MSFT)
Daniel Rodríguez
Deyaaeldeen Almahallawi
Jose Manuel Heredia Hidalgo
bashiMoha
Chidozie Ononiwu
KarishmaGhiya
chradek
Richard Park