[pull] main from microsoft:main #857
Open
+3,281,831
−2,004,146
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
github-actions
bot
added
documentation
pull
bot
added
⤵️ pull
and removed
documentation
github-actions
bot
added
base: main
area: dds
area: examples
documentation
|
🔗 Found some broken links! 💔 Run a link check locally to find them. See linkcheck output
|
github-actions
bot
added
area: server
area: dds: propertydds
area: dev experience
area: website
area: runtime
area: tests
area: loader
dependencies
tag asserts for 2.20
3rd time.
Bumped client from 2.20.0 to 2.21.0.
…elease levels. (#23533) Since we generate API reports for different release levels, it is possible (and valid) for `@link` tags to reference an API item that won't be visible at that level. Currently, our configurations forbid such links as a side-effect of running link validation during report generation (where APIs will be omitted from report consideration based on their release tags. However, it is often useful for APIs to link to more experimental APIs for discoverability. To make this possible, link validation is now disabled in report generation configurations. It is maintained in model generation configs, which is where we really need it. Also adds a couple of such links in the `tree` package as a test (and because we wanted them there).
…push` rule (#23632) Reports false positives for methods named "push" on non-array objects.
…ion to leverage new hierarchy options (#23602) The default suite structure has been updated as follows: - `Package` and `Namespace` items now generate documents _inside_ of their own folder hierarchy, yielding documents named "index". - `Enum` and `TypeAlias` items now generate their own documents (rather than being rendered as sections under their parent document). E.g., old output would likely look something like ``` - index.md - package-a.md - package-a/ - foo.md - ... - package-b.md - package-b/ - bar.md - ... ``` And the new output would likely look more like: ``` - index.md - package-a/ - index.md - foo.md - ... - package-b/ - index.md - bar.md - ... ``` Updates to the `default-config` test assets demonstrate the difference. Also update the `spase-config` test suite to move the package documents under their own hierarchy to be more demonstrative of what an expected use case would likely look like. Other test cases have been updated to maintain existing behavior, accounting for the new defaults. [AB#24263](https://dev.azure.com/fluidframework/235294da-091d-4c29-84fc-cdfc3d90890b/_workitems/edit/24263)
…commended" config and fix violations (#23609) One in a series of PRs working towards migrating the package to our `recommended` config. Enables the following rules, which are included in our "recommended" config: - `unicorn/catch-error-name` - `unicorn/consistent-destructuring` - `unicorn/new-for-builtins` - `unicorn/no-array-callback-reference` - `unicorn/no-array-for-each` - `unicorn/no-null` - `unicorn/no-zero-fractions` - `unicorn/prefer-node-protocol` - `unicorn/prefer-number-properties` - `unicorn/prefer-optional-catch-binding` - `unicorn/prefer-spread` - `unicorn/prefer-string-slice` - `unicorn/switch-case-braces` - `unicorn/throw-new-error` [AB#3027](https://dev.azure.com/fluidframework/235294da-091d-4c29-84fc-cdfc3d90890b/_workitems/edit/3027)
…al (#23634) The `uriRoot` parameter is an option for changing the root path for all generated links. A sensible default for this parameter is nothing (i.e. `""`). This PR makes the parameter optional, and simplifies a couple of test cases by omitting that value.
…es and examples (#23635) While "" and "." for are potentially comparable for a URI root (system dependent), the leading "." makes routes look like relative file paths, which is misleading. Update documentation and tests to use "" instead of ".".
The Jest CLI `--ci` flag cannot be set in its config file like other settings, but it [defaults to isCI from the is-ci package](https://github.com/jestjs/jest/blob/d051b0da359c5930ab4c3ea69fe5524266622c96/packages/jest-cli/src/cli/args.ts#L126), which in turn uses ci-info, which [supports azure](https://github.com/watson/ci-info#supported-ci-tools). So the flag should already be set to true by default in CI even without setting it explicitly. However, to be capable of running tests in an environment as close to CI as possible, even when running locally, the scripts have been updated to pass the `--ci` flag whenever jest is invoked.
## Description Changes that result from adding a dependency somewhere, doing `pnpm i --no-frozen-lockfile`, removing the dependency, and doing `pnpm i --no-frozen-lockfile` again. Seems to be a lot of churn that the upgrade to pnpm v9 should have applied but didn't. A couple breaking changes in [the v9 release notes](https://github.com/pnpm/pnpm/releases/tag/v9.0.0) talk about peer dendencies, which (part of?) this seems to be related to.
This change is just cleanup of deprecated things which are unused, internal, and/or unexported.
This change removes unnecessary ContainerRuntime members. These members just increased complexity of the class, and most could be moved to just be function scoped variables.
This is an effort to reduce time consumed by our client pipeline, parallelizing our tests running them on different agents. With this change we're able to reduce the time from an average of 54min to 38min, writing also the foundations to further parallelization that could keep improving the time all the way down to 25 min on my estimations but which work requires more than this wave of changes. On a nutshell, this change creates a different template from which the client pipeline runs, which main difference is the creation of an artifact that contains some of the build output to be able to run tests on different agents. After several optimizations, by publishing content generated inside lib/dist directories and restore this content in a different agent (once we have checked out the repo and install dependencies), we're able to run our ci tests without needing to run the build process again. <img width="232" alt="image" src="https://github.com/user-attachments/assets/9503bfde-c5ad-4676-8dfd-a7fcb8ae4a3b" /> Some caveats: - Losing some code coverage: given the way coverage works, coverage tests need to be run in the same agent. By running mocha and local e2e tests in the same agent, we're able to keep coverage logic in place altough we will lose coverage done by jest tests. - jests tests need to run the build: for unknown reasons, jests tests are the only ones failing with current approach of consuming lib/dist directories. I even tried getting output.log and tsbuildinfo files but yet there is something generated by the build necessary for these tests to run, so for now we could also run c:build with these tests. It does not matter in terms of time since tests don't consume a lot of time. - repeated logic on our templates: new template shares a lot of logic with build-npm-package.yml since it started as a copy of it. Also it has a lot of logic that does not need to be there since we now know it will only run for client. I don't consider these to be blocking current PR but I would like to attend this in a future PR - More agent creation: more agents are created in our pipelines given this approach so I'll do some testing to make sure there is no unexpected behavior when multiple pipeline runs at the same time. - further parallelization: A lot of these caveats need to be solved to further parallelize these tests. For example, we could split our e2e t9s tests into 2, reducing significantly the time they consume. I believe we could further reduce pipeline duration to 25-28min with further investing. --------- Co-authored-by: Alex Villarreal <716334+alexvy86@users.noreply.github.com>
## Description - Removes the `eslint-plugin-deprecation` package which we apparently weren't using (only present in two packages, not across the repo, and nowhere does an eslint config extend from `plugin:deprecation/recommended` or use the `deprecation/deprecation` rule). We already use `import/no-deprecated` so it seems redundant anyway. - Adds a dependency on `"fluid-framework": "^1.4.0"`, to `packages/service-clients/end-to-end-tests/azure-client`, since `azure-client@^1.2.0` requires it as a peer. Currently the version being resolved was the one from the repo, which maybe speaks well about compatibility? But maybe we just didn't exercise it enough to notice problems. - Adds a dependency on `"scheduler": "^0.20.0"` to `packages/tools/devtools/devtools-view` since it's a required peer dep of some `@fluentui/*` packages it uses.
The following types in the `@fluidframework/container-runtime` are deprecated. These types are unnecessary for external users of this package. - currentDocumentVersionSchema - DeletedResponseHeaderKey - DocumentSchemaValueType - DocumentsSchemaController - GCFeatureMatrix - GCNodeType - GCVersion - IBlobManagerLoadInfo - ICancellableSummarizerController - ICancellationToken - IConnectableRuntime - IContainerRuntimeMetadata - ICreateContainerMetadata - IDocumentSchema - IDocumentSchemaChangeMessage - IDocumentSchemaCurrent - IDocumentSchemaFeatures - IGCMetadata - IGCStats - IMarkPhaseStats - IRefreshSummaryAckOptions - ISerializedElection - ISubmitSummaryOptions - ISummarizerInternalsProvider - ISummarizerRuntime - ISummaryCancellationToken - ISummaryMetadataMessage - ISweepPhaseStats - Summarizer related #23644 --------- Co-authored-by: Matt Rakow <ChumpChief@users.noreply.github.com>
Updates the routerlicious and tinylicious docs to clarify how to set config settings via environment variables, including adjusting the logging levels of tinylicious. --------- Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
…n V2 dropdown (#23613) ## Fix Screen reader is not announcing the index numbers for the items in V2 dropdown ### How to test - Enable VoiceOver for mac, cmd + F5, or Narrator for windows - Open the link [Fluid Framework Documentation | Fluid Framework](https://fluidframework.com/docs/) - Tab till V2 dropdown in header. - Hit enter. - Using down arrow key navigate to the items in dropdown. - Observe that Screen reader is not announcing the index numbers for the items in V2 dropdown.
## Description Adjusts the `timeoutPromise` calls in the attach lifecycle test suite to use the default behavior of waiting until *just before* the test times out rather than half the duration of the test. The previous behavior effectively enforced that every operation completed within half the test timeout, or 2.5s on tinylicious. That is indeed true most of the time, but because we run so many variants of this test, it has been mildly flaky on CI. After this change, we just enforce that the overall test completes within 5s. There have been 6 hits recently for tinylicious, with 4 of them timing out on a promise near the start of the test duration. Here's a column chart of number of test runs vs duration in ms:  Interestingly, we have some passed runs over 3 second long. This suggests some of the runs we're timing out because of one particular step may not have even gone over 5 seconds. The long tail here might mean we eventually want to also bump the t9s timeout for this test suite, but we can evaluate that later using similar techniques. Co-authored-by: Abram Sanderson <absander@microsoft.com>
## Summary of changes The presence-tracker example has been updated to use the presence package. It now uses LatestValueManagers for mouse and focus tracking. Each client also has a slider that controls the allowable latency of the mouse updates. This enables quick demos of the differences in behavior with higher latencies as well as demonstrating runtime adjustments of the allowable latency. ## Known issues: - The failing test checks that when a second client joins the first client's client list is updated. This failure seems to indicate that the multi-client setup is not working correctly. Follow-up issue: [AB#28502](https://dev.azure.com/fluidframework/235294da-091d-4c29-84fc-cdfc3d90890b/_workitems/edit/28502)
…Runtime boundary (#22877) ## Description Added `supportedFeatures` and `generation`properties to Runtime and Loader layer boundary. These will be used to validate that the layers are compatible. These two properties along with `pkgVersion` are added to a `ILayerCompatDetails` interface. `ContainterContext` and `ContainerRuntime` implements this interface provider and uses the provider pattern to access it from the other object. The `interface` is internal and is not exposed since this in an internal implementation. `pkgVersion` is includes in the error / warning logs to give additional context to users as to what the incompatible version combination is. Also, added a `ILayerCompatSupportRequirements` interface that has properties that a layer requires other layer to be at to be compatible. ### Supported features - Both the Runtime and Loader layers have a `supportedFeatures` property that includes a set of features that a layer supports. This is advertised to the other layer at the layer boundary. - Both the layers have a `requiredFeatures` array that includes a set of features that it requires the other layer to support in order to be compatible. _Note that this is internal to that layer and is not advertised._ - At runtime, each layer validates that all the entries in `requiredFeatures` is present in the `supportedFeatures` of the other layer. If not, it closes the container with a usage error that says layers are not compatible. - Any change that adds new behavior or changes existing behavior across a layer boundary must add an entry to the supported features set. For example, changes such as "move writing protocol tree to summary from Loader to Runtime" should add an entry to the supported features set. ### Generation - In addition to supported features, a `generation` is also added to both the layers. This is advertised to the other layer at the layer boundary. - Generation is an integer which will be incremented every month. It will be used to validate compatibility more strictly (time-based) than supported features where layers are incompatible only if there are unsupported features. _Note: The logic to update the generation will be added in a later PR. See [AB#27054](https://dev.azure.com/fluidframework/235294da-091d-4c29-84fc-cdfc3d90890b/_workitems/edit/27054) for a proposed solution._ - One key reason for adding generation is to have a clear cut off point where we officially stop supporting layer combinations. Our compat tests will test combinations up to this cut off point. The idea is that we test what we support and whatever we don't test should not be supported. This will help us achieve that. - Say that Runtime / Loader compatibility is N months. We can start throwing warnings when the layers are almost N-months apart saying that this combination is not supported. This will give applications an early signal that layers are about to be incompatible and they can take necessary steps. We can also choose to close the container if we decide to be strict about the layer combinations. - Both the layers have a `minSupportedGeneration` that it needs the other layer to be at. _Note that this is internal to that layer and is not advertised._ - At runtime, each layer validates that the `generation` of the other layer is >= `minSupportedGeneration`. - For example, say that the Runtime is at generation 20 and has a `minSupportedGeneration` of 8 for the Loader layer (12 month support window). If it sees that Loader's generation is lower than 8, the layers are incompatible. ### Backwards compatibility To support older layers before layer compat enforcement is introduced, the `minSupportedGeneration` is set to 0 whereas `generation` starts at 1. For older layers that did not implement `ILayerCompatDetails`, their generation is set to 0 and supported features is set to an empty set. So, their generation is compatible until we update the `minSupportedGeneration`. [AB#20805](https://dev.azure.com/fluidframework/235294da-091d-4c29-84fc-cdfc3d90890b/_workitems/edit/20805)
… options (#23504) Update dev dependency on `@fluid-tools/api-markdown-documenter` and leverage new "hierarchy" capabilities to move "folder" item documents (packages and namespaces) _into_ their folders, renamed to `index`. E.g., File structure before: ``` | fluid-framework.md | fluid-framework | foo.md | ... ``` After: ``` | fluid-framework | index.md | foo.md | ... ``` This makes the breadcrumbs and navigation drop-downs generated by docusaurus better match the intended hierarchy. E.g., Namespace appearance in the nav before:  - Note that there is a separate page and folder, and selecting the folder doesn't navigate to the page; it just functions as a drop-down. Namespace appearance after:  Breadcrumb before:  - Note that the parent folder isn't selectable, because Docusaurus doesn't understand that it's supposed to point to the document of the same name. Breadcrumb after:  - Note that the parent entry is now selectable (screenshot was taken with mouse hovering over item) [AB#24263](https://dev.azure.com/fluidframework/235294da-091d-4c29-84fc-cdfc3d90890b/_workitems/edit/24263)
…y breaking minor releases (#23603) This PR fixes N-X version calculation to take into account the new legacy breaking minor releases. For example, - For `2.0.0 <= N < 2.10.0`, N-1 is 2.0.0-rc.5.0.x. - For `2.10.0 <= N < 2.20.0`, N-1 is 2.5.x (latest minor between 2.0 and 2.10 is 2.5.x) - For `2.20.0 <= N < 2.30.0`, N-1 is 2.13.x (latest minor between 2.10 and 2.20 is 2.13.x) We should still consider a full rewrite of version calculation, since the code is extremely messy and hard to follow for developers not familiar with it already. However, this change is needed to ensure we continue testing properly in the meantime. See [AB#8198](https://dev.azure.com/fluidframework/235294da-091d-4c29-84fc-cdfc3d90890b/_workitems/edit/8198) for more details. [AB#28437](https://dev.azure.com/fluidframework/235294da-091d-4c29-84fc-cdfc3d90890b/_workitems/edit/28437)
## Description Add a new "debugAssert" API which can be used to add asserts which can be optionally enabled when debugging, and compiled out of production builds. One usage of this was added to tree. This was used to manually test that the tree bundle grew if adding this assert using the regular assert API, but had no change (0 bytes) when adding the assert using the new debugAssert API.
- Removed [unused] production dependencies: `map` and `runtime-utils` - Import `SharedMap` and `SharedTree` from `fluid-framework`. - `SharedTree` is different between `tree` and `fluid-framework` exports. The test code that is using `SharedTree` wants to use the `fluid-framework` `@public` version but was using the `@legacy` version from `tree`. (Really `tree` should expose both, but it is understandable why it is the way it is.) - For best patterns and consistency, `SharedMap` should be pulled from `fluid-framework` instead of `map`. - Then neither `map` nor `tree` are required dependencies and are removed. - Removed dev dependencies: aqueduct
…d cleanup (#23651) - renames a weak map to be more accurate - removes tryGetTreeNodeFromMapNode and replaces it with a restricted version of the original map
We already run CodeQL in the main build job, so we don't need to run it again on test jobs.
Update type tests according to our wiki.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )