[AutoPR @azure/arm-cosmosdb] [MaterializedViews] Updating swagger with Cassandra materialized view API's

.scripts/common.ts

@@ -107,8 +107,8 @@ function isPackageFolderPath(folderPath: string, packagesToIgnore: string[]): bo
   const packageJsonFilePath: string = joinPath(folderPath, "package.json");
   if (fileExistsSync(packageJsonFilePath)) {
     const packageJson: PackageJson = readPackageJsonFileSync(packageJsonFilePath);
-    // Skip all perf framework projects from gulp pack
-    if (packageJson?.name?.startsWith("@azure-tests/")) {
+    // Skip all packages other than track1 arm packages by gulp script in feature/v4 branch
+    if (!packageJson?.name?.startsWith("@azure/arm-")) {
       return false;
     }
     result = !contains(packagesToIgnore, packageJson.name!);

CONTRIBUTING.md

@@ -51,7 +51,7 @@ Rush provides many benefits:
 - When a change is made in a local dependency, Rush will detect that the dependency is dirty and will rebuild it if you attempt to build a project that consumes that dependency.
 - Rush runs project tasks in parallel, subject to the inter-project dependencies that it detects. It also performs incremental builds by default, not rebuilding anything unnecessary (unless you tell it to).
 
-Not every library in the repository is managed by Rush yet, only those listed in the `projects` property in [rush.json](https://github.com/Azure/azure-sdk-for-js/blob/master/rush.json). Packages not managed by Rush can still be managed using `npm`.
+Not every library in the repository is managed by Rush yet, only those listed in the `projects` property in [rush.json](https://github.com/Azure/azure-sdk-for-js/blob/main/rush.json). Packages not managed by Rush can still be managed using `npm`.
 
 ## Setting up your environment
 
@@ -72,7 +72,7 @@ With GitHub's Codespaces, the container already has all prerequisites installed.
 If you prefer to setup your own environment instead, make sure you have these prerequisites installed and available on your `$PATH`:
 
 - Git
-- Node 8.x or higher
+- Any of the [LTS versions of Node.js](https://nodejs.org/about/releases/)
 - Rush 5.x
   - Install / update Rush globally via `npm install -g @microsoft/rush`.
   - Rush will automatically manage the specific version needed by this repo as long as you have any v5 version installed.
@@ -91,7 +91,7 @@ To build packages managed by Rush:
 
 To build packages not managed by Rush:
 
-4. Navigate to the package directory as described in our [repository structure](https://github.com/Azure/azure-sdk/blob/master/docs/policies/repostructure.md)
+4. Navigate to the package directory as described in our [repository structure](https://github.com/Azure/azure-sdk/blob/main/docs/policies/repostructure.md)
 5. Install the package dependencies (`npm install`)
 6. Build the package (`npm run build`)
 
@@ -134,7 +134,7 @@ By default, Rush only displays things written to `STDERR`. If you want to see th
 
 If you want to run the tests of a specific project, go to that project's folder and execute `rushx test`. All of the tests will automatically run both in NodeJS and in the browser. To target these environments individually, you can run `rushx test:node` and `rushx test:browser`.
 
-By default, these npm scripts run previously recorded tests. The recordings have been generated by using a custom recording library called [test-utils-recorder](https://github.com/Azure/azure-sdk-for-js/blob/master/sdk/test-utils/recorder/README.md). We will examine how to run recorded tests and live tests in the following sections.
+By default, these npm scripts run previously recorded tests. The recordings have been generated by using a custom recording library called [test-utils-recorder](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/test-utils/recorder/README.md). We will examine how to run recorded tests and live tests in the following sections.
 
 #### Recorded tests
 
@@ -152,15 +152,15 @@ The readme file in the `test` folder of each package lists the Azure resources a
 
 > Note: Our projects use dotenv to allow you to use `.env` files to set environment variables. Find the `sample.env` file nearest to the project you want to test to see a template of the expected `.env` file.
 
-You can create the necessary Azure resources on your own, or automate this process by using the script called `New-TestResources.ps1` which uses ARM templates defined in a file named `test-resources.json` that exists in each project's folder. Follow the steps in [`Example 1 of New-TestResources.ps1`](https://github.com/Azure/azure-sdk-for-js/blob/master/eng/common/TestResources/New-TestResources.ps1.md#example-1) to set up a service principal and deploy the live test resources.
+You can create the necessary Azure resources on your own, or automate this process by using the script called `New-TestResources.ps1` which uses ARM templates defined in a file named `test-resources.json` that exists in each project's folder. Follow the steps in [`Example 1 of New-TestResources.ps1`](https://github.com/Azure/azure-sdk-for-js/blob/main/eng/common/TestResources/New-TestResources.ps1.md#example-1) to set up a service principal and deploy the live test resources.
 
 #### Regenerating recordings
 
 If you modify the network calls (both the number of calls or their shape) either by changing the tests or source code of the project you're working on, the recordings will need to be re-generated.
 
 Regenerating the recordings has the same requirements as running the live tests. You will be using the same `test` npm script with the environment variables pointing to previously created Azure resources. The only difference is that the `TEST_MODE` environment variable needs to be set to `record`. When this process finishes without errors, the recordings will be updated.
 
-For more information the recorder, please visit the [test-utils-recorder's readme](https://github.com/Azure/azure-sdk-for-js/blob/master/sdk/test-utils/recorder/README.md).
+For more information the recorder, please visit the [test-utils-recorder's readme](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/test-utils/recorder/README.md).
 
 ### Other NPM scripts
 
@@ -239,20 +239,20 @@ We used to have a git hook that formats your changed files on commit but it was
 
 ### Enforcing Azure SDK design guidelines
 
-Our libraries follow the [TypeScript SDK design guidelines](https://azure.github.io/azure-sdk/typescript_introduction.html) to enhance the productivity of developers connecting to Azure services. These guidelines are enforced by our custom [ESLint plugin](https://github.com/Azure/azure-sdk-for-js/tree/master/common/tools/eslint-plugin-azure-sdk). Follow these instruction to use the plugin:
+Our libraries follow the [TypeScript SDK design guidelines](https://azure.github.io/azure-sdk/typescript_introduction.html) to enhance the productivity of developers connecting to Azure services. These guidelines are enforced by our custom [ESLint plugin](https://github.com/Azure/azure-sdk-for-js/tree/main/common/tools/eslint-plugin-azure-sdk). Follow these instruction to use the plugin:
+
 - [add `eslint` to your `devDependencies`](https://github.com/Azure/azure-sdk-for-js/blob/8ec9801c17b175573a115fc8b2d6cbaeb17b0b09/sdk/template/template/package.json#L106)
 - [add `eslint-plugin-azure-sdk` to your `devDependencies`](https://github.com/Azure/azure-sdk-for-js/blob/8ec9801c17b175573a115fc8b2d6cbaeb17b0b09/sdk/template/template/package.json#L93)
 - add a linting npm script as follows:
-    - ["lint": "eslint package.json api-extractor.json src test --ext .ts"](https://github.com/Azure/azure-sdk-for-js/blob/8ec9801c17b175573a115fc8b2d6cbaeb17b0b09/sdk/template/template/package.json#L49)
+  - ["lint": "eslint package.json api-extractor.json src test --ext .ts"](https://github.com/Azure/azure-sdk-for-js/blob/8ec9801c17b175573a115fc8b2d6cbaeb17b0b09/sdk/template/template/package.json#L49)
 
 You can run the plugin by excuting `rushx lint` inside your package directory.
 
-If the package is internal, it should not follow the design guidelines and in turn should not be linted by the plugin. In this case, use the [internal configuration file](https://github.com/Azure/azure-sdk-for-js/blob/master/sdk/.eslintrc.internal.json) instead. For example: `"lint": "eslint --no-eslintrc -c ../../.eslintrc.internal.json package.json package.json src test --ext .ts"`
-
+If the package is internal, it should not follow the design guidelines and in turn should not be linted by the plugin. In this case, use the [internal configuration file](https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/.eslintrc.internal.json) instead. For example: `"lint": "eslint --no-eslintrc -c ../../.eslintrc.internal.json package.json package.json src test --ext .ts"`
 
 ## Onboarding a new library
 
-All libraries must follow our [repository structure](https://github.com/Azure/azure-sdk/blob/master/docs/policies/repostructure.md) (specifically, it must be located at `sdk/<servicename>/<packagename>`) and your library's `package.json` must contain the required scripts as documented [above](#other-npm-scripts).
+All libraries must follow our [repository structure](https://github.com/Azure/azure-sdk/blob/main/docs/policies/repostructure.md) (specifically, it must be located at `sdk/<servicename>/<packagename>`) and your library's `package.json` must contain the required scripts as documented [above](#other-npm-scripts).
 
 The repository contains two different sets of libraries, each follows different rules for development and maintaining. The first type is generated automatically from the [swagger specifications](https://github.com/Azure/azure-rest-api-specs) and their code should not be edited by hand. Onboarding such library is just a matter of pushing its auto-generated directory to the right location in the repository.
 

README.md

@@ -35,19 +35,19 @@ Libraries which enable you to provision specific resources. They are responsible
 - For detailed documentation visit our [Azure SDK for JavaScript documentation](https://aka.ms/js-docs)
 - File an issue via [GitHub Issues](https://github.com/Azure/azure-sdk-for-js/issues)
 - Check [previous questions](https://stackoverflow.com/questions/tagged/azure-sdk-js) or ask new ones on StackOverflow using `azure-sdk-js` tag.
-- Read our [Support documentation](https://github.com/Azure/azure-sdk-for-js/blob/master/SUPPORT.md).
+- Read our [Support documentation](https://github.com/Azure/azure-sdk-for-js/blob/main/SUPPORT.md).
 
 ### Community
 
-Try our [community resources](https://github.com/Azure/azure-sdk-for-js/blob/master/SUPPORT.md#community-resources).
+Try our [community resources](https://github.com/Azure/azure-sdk-for-js/blob/main/SUPPORT.md#community-resources).
 
 ### Reporting security issues and security bugs
 
 Security issues and bugs should be reported privately, via email, to the Microsoft Security Response Center (MSRC) <[email protected]>. You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your original message. Further information, including the MSRC PGP key, can be found in the [Security TechCenter](https://www.microsoft.com/msrc/faqs-report-an-issue).
 
 ## Contributing
 
-For details on contributing to this repository, see the [contributing guide](https://github.com/Azure/azure-sdk-for-js/blob/master/CONTRIBUTING.md).
+For details on contributing to this repository, see the [contributing guide](https://github.com/Azure/azure-sdk-for-js/blob/main/CONTRIBUTING.md).
 
 This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit
 https://cla.microsoft.com.

common/config/rush/common-versions.json

@@ -45,8 +45,12 @@
     // when there is a new beta version which is being maintained in the repo.
     // Remove "^12.4.1" when the storage-blob releases a stable version.
     // Add a new entry in case a new version is being tested through the perf tests (Example: "12.2.0").
-    "@azure/storage-blob": ["^12.4.1"],
-    "@azure/ms-rest-js": ["^2.0.0"],
+    "@azure/storage-blob": [
+      "^12.4.1"
+    ],
+    "@azure/ms-rest-js": [
+      "^2.0.0"
+    ],
     /**
      * For example, allow some projects to use an older TypeScript compiler
      * (in addition to whatever "usual" version is being used by other projects in the repo):
@@ -55,23 +59,36 @@
     //   "~2.4.0"
     // ]
     // Following is required to allow for backward compatibility with Event Processor Host Track 1
-    "@azure/event-hubs": ["^2.1.4"],
-    "@opentelemetry/api": ["^0.18.1"],
+    "@azure/event-hubs": [
+      "^2.1.4"
+    ],
     // Monitor: Allow node 10 types until Timeout / Timer conflict is resolved in OpenTelemetry repo
     // TODO: remove when released https://github.com/open-telemetry/opentelemetry-js/pull/1352
     // eslint v7.15 needs node v10.12
-    "@types/node": ["^10.0.0", "^10.12.0"],
-    // @azure/test-utils-perfstress should depend on lowest version of @azure/core-http for maximum compatibility, allowing test
-    // projects to choose a higher version if desired.
-    "@azure/core-http": ["^1.0.0"],
-    // @azure/container-registry and perf test are using the beta version in the repo.
-    "@azure/core-rest-pipeline": ["1.1.0-beta.4"],
+    "@types/node": [
+      "^10.0.0",
+      "^10.12.0"
+    ],
     // @azure/event-processor-host is on a much lower major version
-    "@azure/ms-rest-nodeauth": ["^0.9.2"],
+    "@azure/ms-rest-nodeauth": [
+      "^0.9.2"
+    ],
     // Idenity is moving from v1 to v2. Moving all packages to v2 is going to take a bit of time, in the mean time we could use v2 on the perf-identity tests.
-    "@azure/identity": ["2.0.0-beta.3", "^1.1.0"],
+    "@azure/identity": [
+      "^2.0.0-beta.4",
+      "2.0.0-beta.3",
+      "^1.1.0"
+    ],
     // Issue #14771 tracks updating to these versions
-    "@microsoft/api-extractor": ["7.13.2"],
-    "prettier": ["2.2.1"]
+    "@microsoft/api-extractor": [
+      "7.13.2"
+    ],
+    "prettier": [
+      "2.2.1"
+    ],
+    // @azure/cosmos was unable to upgrade due to test failures, Issue #15928 tracks making this upgrade
+    "@azure/core-rest-pipeline": [
+      "^1.0.3"
+    ]
   }
 }