Add feedback links to all the files (#11317)
This commit is contained in:
Chad Nedzlek
GitHub
Родитель
ec89a0fda9
Коммит
758b26a790
|
|
@ -396,3 +396,8 @@ Below are listed various tools and commands useful for the Coherency QB.
|
|||
flow graph. See example in linked docs.
|
||||
|
||||
[open-dependency-prs]: https://github.com/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+author%3Aapp%2Fdotnet-maestro+archived%3Afalse+user%3Adotnet+user%3Aaspnet+
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5C3xReleaseShutdownTasks.md) [](https://helix.dot.net/f/n/5?p=Documentation%5C3xReleaseShutdownTasks.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -27,3 +27,8 @@ If your project depend on a package which is also part of the .NET SDK used by A
|
|||
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CArcadeConventions.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CArcadeConventions.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Arcade SDK
|
||||
# Arcade SDK
|
||||
|
||||
Arcade SDK is a set of msbuild props and targets files and packages that provide common build features used across multiple repos, such as CI integration, packaging, VSIX and VS setup authoring, testing, and signing via Microbuild.
|
||||
|
||||
|
|
@ -1027,3 +1027,8 @@ If set to true calls to GetResourceString receive a default resource string valu
|
|||
|
||||
#### `GenerateResxSourceOmitGetResourceString` (bool)
|
||||
If set to true the GetResourceString method is not included in the generated class and must be specified in a separate source file.
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CArcadeSdk.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CArcadeSdk.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -132,3 +132,8 @@ From time to time, there are some terms you might encounter in documentation or
|
|||
|
||||
- collection --> account --> instance (top level thing - e.g. dev.azure.com/dnceng)
|
||||
- team --> group of individuals. Largely is about the backlog, not much more. In our case we're not using for permissions.
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CAzureDevOps%5CAzureDevOpsGuidance.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CAzureDevOps%5CAzureDevOpsGuidance.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -198,3 +198,8 @@ For a list of known Azure DevOps issues we are tracking, please go [here](https:
|
|||
`An error occurred while loading the YAML Pipeline. Repository self references endpoint 6510879c-eddc-458b-b083-f8150e06ada5 which does not exist or is not authorized for use`
|
||||
|
||||
The problem is the yaml file had a parse error when the definition was originally created. When the definition is created, parse errors are saved with the definition and are supposed to be shown in the definition editor. That regressed in the UI. Azure DevOps is also making a change so that even if there are errors parsing the file, they go ahead and save the repository endpoint as authorized. In the mean time, you have to track down your YAML parse error.
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CAzureDevOps%5CAzureDevOpsOnboarding.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CAzureDevOps%5CAzureDevOpsOnboarding.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -41,3 +41,8 @@ This is because RepoToolset is expecting a GitHub url but internal builds are bu
|
|||
## Agent pools
|
||||
|
||||
See [Azure DevOps Onboarding documentation](./AzureDevOpsOnboarding.md#agent-queues)
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CAzureDevOps%5CMovingFromDevDivToDncEng.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CAzureDevOps%5CMovingFromDevDivToDncEng.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -383,3 +383,8 @@ matrix: { string: { string: string } }
|
|||
#### job
|
||||
|
||||
The job schema has replaced the phase schema and is publicly [documented](https://docs.microsoft.com/en-us/azure/devops/pipelines/yaml-schema?view=vsts&tabs=schema#job)
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CAzureDevOps%5CPhaseToJobSchemaChange.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CAzureDevOps%5CPhaseToJobSchemaChange.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -156,3 +156,8 @@ As surfaced by the Helix API and backing Kusto (Azure Data Explorer) database, h
|
|||
- PassOnRetry – Special legacy retry functionality which is purposefully obsoleted as it does not play well with Azure DevOps test reporting (reporting the same facts twice causes issues)
|
||||
- Timeout – Work Item did not complete within its specified timeout and was forcibly killed. Corresponds to exit code -3 (made up value since the process never exited)
|
||||
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CAzureDevOps%5CSendingJobsToHelix.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CAzureDevOps%5CSendingJobsToHelix.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -114,3 +114,8 @@ artifacts:
|
|||
artifacts | logs | manifests:
|
||||
name: string # Azure DevOps artifact name
|
||||
```
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CAzureDevOps%5CTemplateSchema.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CAzureDevOps%5CTemplateSchema.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -78,3 +78,8 @@ Notable fields in this table include:
|
|||
**Significance**: The closer this value is to 1, the more likely something changed recently to cause this test to start failing. This value also indicates the difference between "Current" and "Historical"
|
||||
|
||||
**SplitDate**: The date of the first day of the week of data aggregated. This date also represents the difference between the "Current" and "Historical" columns.
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CAzureDevOps%5CTestReportingData.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CAzureDevOps%5CTestReportingData.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -238,3 +238,8 @@ This Power BI page contains the following reports:
|
|||
This report tracks the usage and trends of the feedback we receive via the sentiment tracker in the Build Analysis check on the PRs.
|
||||
|
||||
:part_alternation_mark: [Link](https://msit.powerbi.com/groups/de8c4cb8-b06d-4af8-8609-3182bb4bdc7c/reports/e6deb422-46fc-4f80-8892-ba7036081986/ReportSection) to Power BI Report
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CAzureDevOps%5CTestReportingQueries.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CAzureDevOps%5CTestReportingQueries.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -40,3 +40,8 @@ Pipelines for the .NET Core Ecosystem should be written with the following goals
|
|||
- Allow usage of EOL operating systems to be removed or at least identified more easily.
|
||||
- Simultaneously roll out new changes to repo scripting and pipeline logic.
|
||||
- Update older servicing branches to ensure their pipelines are not broken by changes in external systems.
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CAzureDevOps%5CWritingBuildDefinitions.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CAzureDevOps%5CWritingBuildDefinitions.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -21,3 +21,8 @@ Public code should be mirrored to dev.azure.com/dnceng/internal (see [Azure DevO
|
|||
"actionArguments": {
|
||||
"vsoSourceBranch": "master",
|
||||
```
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CAzureDevOps%5Cinternal-mirror.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CAzureDevOps%5Cinternal-mirror.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -920,3 +920,8 @@ Allow user to modify configuration (branch names, remove subscriptions, add repo
|
|||
**Validate and apply configuration**
|
||||
|
||||
Validate the configuration and then apply the configuration using the [BAR](https://github.com/dotnet/arcade/blob/master/Documentation/Maestro/BuildAssetRegistry.md) REST API.
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CBranchesChannelsAndSubscriptions.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CBranchesChannelsAndSubscriptions.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -34,3 +34,8 @@ All test execution should run through helix. An up to date list of helix queues
|
|||
|
||||
[dotnet-helix-machines]: https://dev.azure.com/dnceng/internal/internal%20Team/_git/dotnet-helix-machines?path=%2FREADME.md&version=GBmain
|
||||
[Helix Queue Info Api]: https://helix.dot.net/swagger/ui/index#!/Information/Information_QueueInfoList
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CChoosingAMachinePool.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CChoosingAMachinePool.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -75,3 +75,8 @@ Language-specific examples and some variations may be found in LGTM's [Alert Sup
|
|||
## Further Reading
|
||||
|
||||
GitHub's official CodeQL documentation: [CodeQL documentation](https://codeql.github.com/docs)
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CCodeQLGuidance.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CCodeQLGuidance.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -56,3 +56,8 @@ The following list provides a summary of the state of each package. For more inf
|
|||
- Make sure what we currently have will work for most repositories. Refactor where necessary.
|
||||
- Add documentation.
|
||||
- **When could start being consumed by other repositories**: S141 => 9/21
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CCorePackages%5CPackagesRoadmap.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CCorePackages%5CPackagesRoadmap.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -3,3 +3,8 @@
|
|||
Currently, the Arcade SDK does not provide any custom packaging logic. It makes use and ***strongly recommend*** that all onboarded repos use the vanilla .NET SDK `dotnet pack` target.
|
||||
|
||||
Some repos (e.g., CoreFX and ASPNet) have mentioned that in some cases custom packaging logic might be needed. Discussion around this is currently in progress [here](https://github.com/dotnet/arcade/issues/383) and the eventual work will be tracked on this [Epic](https://github.com/dotnet/arcade/issues/578).
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CCorePackages%5CPackaging.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CCorePackages%5CPackaging.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -51,3 +51,8 @@ https://github.com/dotnet/arcade/blob/master/Documentation/CorePackages/Publishi
|
|||
|
||||
Additional information about the in-build signing process can be found here:
|
||||
https://github.com/dotnet/arcade/blob/master/Documentation/CorePackages/Signing.md
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CCorePackages%5CPostBuildSigning.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CCorePackages%5CPostBuildSigning.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -527,3 +527,8 @@ Eg:
|
|||
tools/x64_arm64/mscordbi.dll
|
||||
|
||||
During publishing, arcade will pick up SymbolPublishingExclusionsFile.txt and exclude the symbols mentioned in it.
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CCorePackages%5CPublishing.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CCorePackages%5CPublishing.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -260,3 +260,8 @@ The log messages from the SignToolTask itself will be included in the log (+.bin
|
|||
**Target Framework:** valid values include (but are not limited to): `.NETStandard,Version=v2.0`, `.NETFramework,Version=v4.6.1`, `.NET Core,Version=v2.0`, etc.
|
||||
|
||||
**Public Key Token:** valid values are 16 characters in length comprising values between `[0-9]` and `[a-Z]`.
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CCorePackages%5CSigning.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CCorePackages%5CSigning.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -23,3 +23,8 @@ The goal of the signing plan is to provide guidance on how the tier 1 (T1) produ
|
|||
- S138: 7/2 - 7/20
|
||||
- S139: 7/23 - 8/10
|
||||
- S140: 8/13 - 8/31
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CCorePackages%5CSigningPlan.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CCorePackages%5CSigningPlan.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -75,3 +75,8 @@ phases:
|
|||
steps:
|
||||
- template: /eng/code-inspection.yaml
|
||||
```
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CCorePackages%5CTelemetry.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CCorePackages%5CTelemetry.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -237,3 +237,8 @@ Below is a list of the main parameters that control the logic.
|
|||
| VersionPrefix | .NET | Initialized to `$(MajorVersion).$(MinorVersion).0` if not set by the project. |
|
||||
| VersionSuffix | .NET | The suffix part of the version string, including the pre-release portion. |
|
||||
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CCorePackages%5CVersioning.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CCorePackages%5CVersioning.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -2986,3 +2986,8 @@ None.
|
|||
PS C:\enlistments\core-setup> darc verify
|
||||
Dependency verification succeeded.
|
||||
```
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CDarc.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CDarc.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -109,3 +109,8 @@ More information [here]( https://github.com/dotnet/arcade/blob/master/Documentat
|
|||
|
||||
## Speculative product build
|
||||
More information [here](https://github.com/dotnet/arcade/blob/master/Documentation/Maestro.md#speculative-product-builds).
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CDependenciesFlowPlan.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CDependenciesFlowPlan.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -161,3 +161,8 @@ The dependency description is comprised of two types of assets:
|
|||
}
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CDependencyDescriptionFormat.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CDependencyDescriptionFormat.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -203,3 +203,8 @@ To validate that created subscriptions and channels work as expected you'd need
|
|||
- Last Build: N/A
|
||||
```
|
||||
2. Incase of any errors contact @dnceng.
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CDependencyFlowOnboarding.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CDependencyFlowOnboarding.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -79,3 +79,8 @@ Publish manifest to BAR
|
|||
### Publishing multiple manifests
|
||||
|
||||
If you have multiple jobs that publish assets, then you need to publish the generated manifests from each of those legs. In Arcade, this is done by publishing each of the manifests as Artifacts to Azure DevOps and then having a [final job](https://github.com/dotnet/arcade/blob/de44b15e79b9d124d04c16458bead2a1d7ea02ef/eng/common/templates/job/publish-build-assets.yml) that runs and downloads the manifests / publishes them all to BAR
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CDependencyFlowOnboardingWithoutArcade.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CDependencyFlowOnboardingWithoutArcade.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -65,3 +65,8 @@ In other to later build reporting for known issues, we will save the following i
|
|||
|
||||
- Once a new known issue is submitted, regenerate build analysis check for affected builds
|
||||
- Regenerate build analyses check once a potential new known issue is submitted
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CDevWorkflow%5CDesign%5CDev-Design-Infra-Known-Issues.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CDevWorkflow%5CDesign%5CDev-Design-Infra-Known-Issues.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -82,3 +82,8 @@ True if the property contains (case-insensitive) the value string
|
|||
The same as a raw string, but "*" can match any number of characters, and "?" can match one character
|
||||
#### {"regex": "value with .* regex"}
|
||||
true if the propety matches the regular expression
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CDevWorkflow%5CDesign%5CDev-Design-Test-Configuration-Json.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CDevWorkflow%5CDesign%5CDev-Design-Test-Configuration-Json.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -69,3 +69,8 @@ BuildId | I32 | X | X
|
|||
DefinitionId | I32 | X | X
|
||||
DefinitionName | StringBuffer | X | X
|
||||
AggregationDate | DateTimeOffset | | X
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CDevWorkflow%5CDesign%5CDev-Design-Test-Data-Storage.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CDevWorkflow%5CDesign%5CDev-Design-Test-Data-Storage.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -90,3 +90,8 @@ is not well structured for testing.
|
|||
|
||||
Most of the code logic will be made in the helix-machines repository, because that is where the python code resides today. It could theoretically be
|
||||
moved, but the value isn't there for that.
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CDevWorkflow%5CDesign%5CDev-Design-Work-Item-Retry.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CDevWorkflow%5CDesign%5CDev-Design-Work-Item-Retry.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -17,3 +17,8 @@ Issue tracking this failure [dotnet/runtime#1234](https://github.com/dotnet/runt
|
|||
* This step has failed 9 out of 15 runs in master, most recently on 2020-02-09 in build [20200209.11](https://dev.azure.com/dnceng/public/_build/results?buildId=983865&view=logs&j=a39b4a58-e33b-54f5-bd2c-8b6ea43701a1&t=673eb198-64b2-54fc-cc71-ec41376307e1&l=1625)
|
||||
* Errors in this PR:
|
||||
* [[Log]](https://dev.azure.com/dnceng/public/_build/results?buildId=983865&view=logs&j=758ff361-657e-52c7-2383-2c9b9ea87442&t=5bdb2093-eed3-5c87-c252-b435d4bddc4c&l=3038) src/mono/mono.proj(496,5): error MSB3073: The command "cmake --build . --target install --config Debug --parallel 4" exited with code 2.
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CDevWorkflow%5CDesign%5CGitHub-Check-Mockup%5CBuild-Failure-In-Target-Branch.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CDevWorkflow%5CDesign%5CGitHub-Check-Mockup%5CBuild-Failure-In-Target-Branch.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -7,4 +7,8 @@
|
|||
|
||||
## Builds with known failures
|
||||
|
||||
* Build MacCatalyst x64 Debug AllSubsets_Mono / Build Product - dotnet/runtime#12345
|
||||
* Build MacCatalyst x64 Debug AllSubsets_Mono / Build Product - dotnet/runtime#12345
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CDevWorkflow%5CDesign%5CGitHub-Check-Mockup%5CBuild-Failure-Known-Issues.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CDevWorkflow%5CDesign%5CGitHub-Check-Mockup%5CBuild-Failure-Known-Issues.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -12,3 +12,8 @@ Issue tracking this failure [dotnet/runtime#1234](https://github.com/dotnet/runt
|
|||
* Build Android x86 Debug AllSubsets_Mono / Build Product
|
||||
* [[Log]](https://dev.azure.com/dnceng/public/_build/results?buildId=983865&view=logs&j=758ff361-657e-52c7-2383-2c9b9ea87442&t=5bdb2093-eed3-5c87-c252-b435d4bddc4c&l=3038) src/mono/mono.proj(496,5): error MSB3073: The command "cmake --build . --target install --config Debug --parallel 4" exited with code 2
|
||||
* [[Log]](https://dev.azure.com/dnceng/public/_build/results?buildId=983865&view=logs&j=a39b4a58-e33b-54f5-bd2c-8b6ea43701a1&t=673eb198-64b2-54fc-cc71-ec41376307e1&l=1625) command completed with exit code 1
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CDevWorkflow%5CDesign%5CGitHub-Check-Mockup%5CBuild-Failure-Pass-On-Retry.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CDevWorkflow%5CDesign%5CGitHub-Check-Mockup%5CBuild-Failure-Pass-On-Retry.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -21,4 +21,8 @@ To triage this issue:
|
|||
{
|
||||
"errorMessage" : ""
|
||||
}
|
||||
```
|
||||
```
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CDevWorkflow%5CDesign%5CGitHub-Check-Mockup%5CKnown-Issue.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CDevWorkflow%5CDesign%5CGitHub-Check-Mockup%5CKnown-Issue.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -26,3 +26,8 @@ Actual: typeof(System.Net.WebException): An error occurred while sending the r
|
|||
|
||||
<dt>:grey_exclamation: This is a new test, introduced on 2/8</dt>
|
||||
</dl>
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CDevWorkflow%5CDesign%5CGitHub-Check-Mockup%5CTest-Failure-In-Target-Branch.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CDevWorkflow%5CDesign%5CGitHub-Check-Mockup%5CTest-Failure-In-Target-Branch.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -22,3 +22,8 @@ Actual: typeof(System.Net.WebException): An error occurred while sending the r
|
|||
</ul></dd>
|
||||
<dt>:grey_exclamation: This is a new test, introduced on 2/8</dt>
|
||||
</dl>
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CDevWorkflow%5CDesign%5CGitHub-Check-Mockup%5CTest-Pass-On-Retry.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CDevWorkflow%5CDesign%5CGitHub-Check-Mockup%5CTest-Pass-On-Retry.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -14,3 +14,8 @@ There are build failures in this build for pipelines that are not currently fail
|
|||
* :small_blue_diamond: This step is not failing in the [most recent master build](http://bing.com)
|
||||
* ❌ [[Log]](https://dev.azure.com/dnceng/public/_build/results?buildId=983865&view=logs&j=758ff361-657e-52c7-2383-2c9b9ea87442&t=5bdb2093-eed3-5c87-c252-b435d4bddc4c&l=3038) src/mono/mono.proj(496,5): error MSB3073: The command "cmake --build . --target install --config Debug --parallel 3" exited with code 2.
|
||||
* 27 other jobs are failing
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CDevWorkflow%5CDesign%5CGitHub-Check-Mockup%5CUnique-Build-Failure.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CDevWorkflow%5CDesign%5CGitHub-Check-Mockup%5CUnique-Build-Failure.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -73,3 +73,8 @@ Actual: typeof(System.Net.WebException): An error occurred while sending the r
|
|||
</dl>
|
||||
|
||||
#### ... and 3 other tests [[All Test Results]](https://dev.azure.com/dnceng/public/_build/results?buildId=975143&view=ms.vss-test-web.build-test-results-tab)
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CDevWorkflow%5CDesign%5CGitHub-Check-Mockup%5CUnique-Test-Failure.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CDevWorkflow%5CDesign%5CGitHub-Check-Mockup%5CUnique-Test-Failure.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -76,3 +76,8 @@ This list are queues that are hosted in a data center managed by DDFUN. These qu
|
|||
# Build Pools
|
||||
|
||||
This section shows you what build pools are used, separated by 1ES Hosted and Microsoft Hosted. There are hyperlinks here to direct you to documentation about packages and software installed by default on these build machines.
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CDevWorkflow%5CQueue-Insights-Documentation.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CDevWorkflow%5CQueue-Insights-Documentation.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -114,3 +114,8 @@ See [Migrating from v0.2](Migrating-0.2.md).
|
|||
Version 1.0 works always; there is no change needed.
|
||||
|
||||
```
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CDocumentationPrinciples.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CDocumentationPrinciples.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -15,3 +15,8 @@ To retrieve the dump files:
|
|||
3. Click on the `Attachments` tab (not `Attachments*`) to see the UploadFileResults.txt. Click on that file to open the preview.
|
||||
|
||||
4. You will find a list of files that link back to the file that was uploaded to Azure Storage. From there, you can download the dump files or log files or other files that were uploaded as a result from the work item.
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CDumps%5CDumps.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CDumps%5CDumps.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -43,3 +43,8 @@ https://github.com/dotnet/arcade/blob/master/Documentation/RepoToolset/Migration
|
|||
kinks?**
|
||||
|
||||
Sure.
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CFAQ.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CFAQ.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -12,4 +12,8 @@ It runs as a background service. It does the following jobs.
|
|||
- It reads records from the azure table and does a series of further checks to confirm if the commit needs to be mirrored.
|
||||
- It then opens up the PR in the respective repositories, adds the assignees and waits for new candidates.
|
||||
- It makes periodic checks (after every 10 minutes) to the azure table to get the list of commits that has not been mirrored yet. After that it marks those entries as mirrored.
|
||||
- The logging is made to console as well as to a log file to make debugging of the failures easy.
|
||||
- The logging is made to console as well as to a log file to make debugging of the failures easy.
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CGitSyncTools.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CGitSyncTools.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -45,3 +45,8 @@ A major requirement for this system was to be able to execute work across multip
|
|||
|
||||
### Docker Image Support
|
||||
For any Helix queue where Docker is installed (viewable via the Queue info API), work items may be executed in a docker image via the syntax `(Fake.Queue.Name)real.queue.name@docker.tag`. This allows running on OS combinations we either can't install on Azure (e.g. Fedora Linuxes) or which only support Docker (Windows Nano, etc.)
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CHelix.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CHelix.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -159,3 +159,8 @@ In general, we expect most repositories to test against the default tests and co
|
|||
| Csproj | src\benchmarks\micro\MicroBenchmarks.csproj <br> src\benchmarks\real-world\Microsoft.ML.Benchmarks\Microsoft.ML.Benchmarks.csproj <br> src\benchmarks\real-world\Roslyn\CompilerBenchmarks.csproj |
|
||||
| RunCategories | For micro benchmarks: coreclr, corefx <br> For ML benchmarks: mldotnet <br> For Roslyn benchmarks: roslyn|
|
||||
| Kind | For microbenchmarks: micro <br> For ML benchmarks: mlnet <br> For Roslyn benchmarks: roslyn |
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CHowToAddPerfTestingToPipeline.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CHowToAddPerfTestingToPipeline.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -76,3 +76,8 @@ If `TsaNotificationEmail` is set, a notification email will be sent out with a l
|
|||
## See Also
|
||||
- [SDL Control Flow Document](https://dev.azure.com/dnceng/internal/_wiki/wikis/DNCEng%20Services%20Wiki/442/ArcadeSecurityControlFlowDocumentation)
|
||||
- [Introduction to Guardian and TSA](https://dev.azure.com/dnceng/internal/_wiki/wikis/DNCEng%20Services%20Wiki/443/IntroToGuardianAndTSA)
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CHowToAddSDLRunToPipeline.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CHowToAddSDLRunToPipeline.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -43,3 +43,8 @@ One of the goals of Arcade is to be a vehicle to provide code sharing. One of th
|
|||
- [`Overview.md`](Overview.md)
|
||||
|
||||
- [`..\eng\Versions.props`](../eng/Versions.props)
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CHowToCreatePackages.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CHowToCreatePackages.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -32,4 +32,8 @@ When a repo is renamed or moved, a number of things need to be done to ensure a
|
|||
<for each original repository policy on active branches>
|
||||
darc add-repository-policy
|
||||
```
|
||||
- Update the `repositories` variable in GatherDropOperation to point to the new repo name, if that repo is present in the list: https://github.com/dotnet/arcade-services/blob/d2ef862c8262c3945a0c2098c3307ae9e264124a/src/Microsoft.DotNet.Darc/src/Darc/Operations/GatherDropOperation.cs#L336-L380.
|
||||
- Update the `repositories` variable in GatherDropOperation to point to the new repo name, if that repo is present in the list: https://github.com/dotnet/arcade-services/blob/d2ef862c8262c3945a0c2098c3307ae9e264124a/src/Microsoft.DotNet.Darc/src/Darc/Operations/GatherDropOperation.cs#L336-L380.
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CHowToRenameARepo.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CHowToRenameARepo.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -173,3 +173,8 @@ Given the infrastructure ecosystem requirements, this section identifies the set
|
|||
- **Dependency Flow Automation** – A set of tools and services used to automate the movement of dependencies among repositories based on configurable policies. Maestro++ implements most of this functionality, utilizing the repository tooling.
|
||||
- **Visualization/Reporting System** – A set of services used to report the status of the product. Currently implemented in Azure DevOps Tests.
|
||||
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CInfrastructureEcosystemOverview.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CInfrastructureEcosystemOverview.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -45,3 +45,8 @@ For example, a change originating in CoreCLR would have bits flowed in the follo
|
|||
It answers the question of “what would the product (or subproduct) look like if a specific version of a repo was injected into the dependency graph.
|
||||
While these assets are generated in the process of flowing dependencies, the “default” model is to abort the flow if tests fail. When attempting a speculative product build, the flow could be continued, without committing results, as long as builds complete successfully.
|
||||
The important part to recognize is that a speculative product build is NOT a shippable product. It is intended to be used by devs as a “what if” tool to view a commit in context of other repositories.
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CMaestro.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CMaestro.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -131,3 +131,8 @@ class AssetLocation {
|
|||
[Maestro]: ../Maestro.md
|
||||
[DARC]: ../Darc.md
|
||||
[MC]: https://mc.dot.net/
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CMaestro%5CBuildAssetRegistry.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CMaestro%5CBuildAssetRegistry.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -37,3 +37,8 @@ Please check in the logs to validate if requests are still flowing:
|
|||
1. Go to the App Service Editor (preview).
|
||||
2. Download `bin/Microsoft.DotNet.Maestro.dll` and `bin/Microsoft.DotNet.Maestro.WebApi.dll`
|
||||
3. Use ildasm, ILSpy, or some other disassembler to determine if the IL matches the changes you expected.
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CMaestro%5Cdeploy.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CMaestro%5Cdeploy.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -28,3 +28,8 @@ Example web hooks page url: https://github.com/dotnet/versions/settings/hooks/
|
|||
* Active: checked
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CMaestro%5Cweb-hooks.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CMaestro%5Cweb-hooks.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -139,4 +139,8 @@ public bool InvokeExecute(ServiceProvider provider)
|
|||
{
|
||||
return (bool)GetExecuteMethod().Invoke(this, GetExecuteArguments(provider));
|
||||
}
|
||||
```
|
||||
```
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CMechanics%5CMSBuildTaskDependencyInjection.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CMechanics%5CMSBuildTaskDependencyInjection.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -127,3 +127,8 @@ time we are bringing the rest of the test jobs over.
|
|||
|---|---|
|
||||
|1| 12/14/2018 |
|
||||
|2| 03/15/2019|
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CMigrationPlan%5CCoreClrPlan.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CMigrationPlan%5CCoreClrPlan.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -20,3 +20,8 @@ Core-setup
|
|||
Ownership thread needs to be resolved.
|
||||
|
||||
from @danmosemsft on 10/29
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CMigrationPlan%5CCoreFxPlan.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CMigrationPlan%5CCoreFxPlan.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -120,3 +120,8 @@ Now that our primary dependency is on Azure DevOps feeds for .NET Core 3.x, it's
|
|||
| interactive-window | tmat | 2 months ago | tmat |
|
||||
| roslyn-analyzers | roslyn | 1 day ago | roslyn |
|
||||
| roslyn-tools | roslyn | 1 day ago | roslyn |
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CMigrationPlan%5CMyGetFeeds.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CMigrationPlan%5CMyGetFeeds.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -21,3 +21,8 @@ Now that the WebSdk is migrated completely, it should be much easier to complete
|
|||
@Joeloff will be doing the work for both dotnet/Templating & aspnet/WebSDK
|
||||
|
||||
from @vijayrkn on 12/21/2018
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CMigrationPlan%5CTemplatingAndWebSdkPlan.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CMigrationPlan%5CTemplatingAndWebSdkPlan.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -13,3 +13,8 @@ Expected delivery dates:
|
|||
2. 23 November 2018.
|
||||
3. 30 November 2018.
|
||||
4. mid December 2018.
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CMigrationPlan%5CVisualFSharp.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CMigrationPlan%5CVisualFSharp.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -9,3 +9,8 @@ Roslyn
|
|||
1. End of November. Remaining work known
|
||||
1. Will fall out from arcade work
|
||||
1. N/A
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CMigrationPlan%5Croslyn.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CMigrationPlan%5Croslyn.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -159,3 +159,8 @@ Example:
|
|||
I think that this model will allow us to be a bit more flexible in the types of dependencies that we install and provide a method for non-xcopy deployable dependencies to be installed in the future. The tool installers may make use of common libraries for installs though.
|
||||
|
||||
We are looking into improving this experience to genericize the installers and reduce boilerplate.
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CNativeToolBootstrapping.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CNativeToolBootstrapping.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -30,4 +30,8 @@ Once you've executed these steps, you'll be using the native tools installed on
|
|||
|
||||
After switching, the local dev experience will change as devs will be expected to install dependencies ahead of time. Consider
|
||||
creating a document similar to [this](https://github.com/dotnet/runtime/blob/main/docs/workflow/requirements/windows-requirements.md)
|
||||
dotnet/runtime requirements doc.
|
||||
dotnet/runtime requirements doc.
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CNativeToolsOnMachine.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CNativeToolsOnMachine.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -60,3 +60,8 @@ of whether the repo will be within budge once those items are complete.*
|
|||
[red]: https://individual.icons-land.com/IconsPreview/Sport/PNG/16x16/Ball_Red.png
|
||||
[green]: https://individual.icons-land.com/IconsPreview/Sport/PNG/16x16/Ball_Green.png
|
||||
[yello]: https://individual.icons-land.com/IconsPreview/Sport/PNG/16x16/Ball_Yellow.png
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CNet5BuildTImeReductionStatus.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CNet5BuildTImeReductionStatus.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -53,3 +53,8 @@ Repository builds in .NET 5 must be leaner and more efficient than any of our pr
|
|||
- **Add official build validation to repo based on Arcade .yml template**
|
||||
- **Incorporate source-build patches into source**
|
||||
- **Review and approve PRs for incoming source-build implementation**
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CNet5Builds.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CNet5Builds.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -57,3 +57,8 @@ This table represents the status of the .NET 5 Servicing Readiness Test on a Per
|
|||
| wpf | fabiant | ✔️ (64391) | ✔️ (64389) | ❌ |
|
||||
| windowsdesktop | fabiant | ✔️ (64407) | 🚧 (64428) | ❌ |
|
||||
| templating | joaguila | ✔️ | ❌ | ❌ |
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CNet5ServicingReadinessStatus.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CNet5ServicingReadinessStatus.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -196,3 +196,8 @@ There are a number of things that require attention to ensure a working product
|
|||
If significant changes have been made to build definitions or repo infrastructure code, ensuring that this contract is still abided by can ensure a proper isolated product build.
|
||||
- Did all repos update their branding properly?
|
||||
- Are intra-build storage accounts publicly visible? Intra-build storage (typically only used in corefx, coreclr and core-setup) should not be publicly visible in internal build scenarios.
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CNetCore2122ServicingFlow.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CNetCore2122ServicingFlow.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -44,3 +44,8 @@ Target completion date for these workstreams is 12/14/2018.
|
|||
| Complete | All work streams are complete |
|
||||
| On track | Work streams are on track for completion by the target completion date or exceptions are understood / acceptable |
|
||||
| At risk | One or more work streams are not on track to be completed by the target completion date and may impact business decisions |
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CNetCore3EngineeringRepoStatus.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CNetCore3EngineeringRepoStatus.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -76,3 +76,8 @@ pipelines there but we'd need to special case the code and probably modify some
|
|||
| Roslyn | jaredpar | Not-Moved | 4 | Building from devdiv and doing VS Insertion |
|
||||
| Visual-FSharp | brettfo | Not-Moved | 4 | Not using Arcade SDK and building from devdiv |
|
||||
| Core-SDK | licavalc | Not-Moved | 4 | Publishes to two feeds in the same task |
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CNetCore3ReleasePipelinesMoveStatus.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CNetCore3ReleasePipelinesMoveStatus.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -48,3 +48,8 @@
|
|||
Prioritize branches that are producing bits for .NET 5. Given the extended
|
||||
support lifecycle for .NET Core 3.1, backporting infrastructure to .NET Core 3.1
|
||||
release branches is desired, but .NET 5 branches should go first.
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5COnboarding.md) [](https://helix.dot.net/f/n/5?p=Documentation%5COnboarding.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -196,3 +196,8 @@ The parameters that can be passed to the template are as follows:
|
|||
| `JobNameSuffix` | `''` | Allows for custom job name suffix. This is helpful for disambiguation in case of need for more then one OneLocBuild job run - e.g. as a way to set multiple package IDs. |
|
||||
|
||||
It is recommended that you set `LclSource` and `LclPackageId` as shown in the example above.
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5COneLocBuild.md) [](https://helix.dot.net/f/n/5?p=Documentation%5COneLocBuild.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -274,4 +274,8 @@ Pipeline state:
|
|||
Notes:
|
||||
- Anything interesting or unusual that happened as part of this week's check-in.
|
||||
- Issue(s) falling out of the process for this week:
|
||||
```
|
||||
```
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5COperations%5CHelix-Machine-Management%5CHelix-Machine-Lifecycle-Processes.md) [](https://helix.dot.net/f/n/5?p=Documentation%5COperations%5CHelix-Machine-Management%5CHelix-Machine-Lifecycle-Processes.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -77,4 +77,8 @@ This part is more for guidance but can be retained in documents deriving from th
|
|||
|
||||
- Is/are there at least one (ideally two) SME IC(s) listed as contact for clarification?
|
||||
|
||||
- Does the document specify sufficient detail that an artibrary reader would be able to reason about and execute the processes described?
|
||||
- Does the document specify sufficient detail that an artibrary reader would be able to reason about and execute the processes described?
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5COperations%5CTemplates%5Cprocess-info-template.md) [](https://helix.dot.net/f/n/5?p=Documentation%5COperations%5CTemplates%5Cprocess-info-template.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -170,3 +170,8 @@ The DncDevOps team will be focused on 'predictable work' - stuff that doesn't ha
|
|||
## Notes
|
||||
|
||||
This is a draft: This list is currently a set of ideas, with no specific order. Primarily, I am trying to write down things that keep the system going that either don't have a clear ownership today, or for which ownership could be transferred.
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5COperations%5Cdnceng-operational-responsibilities.md) [](https://helix.dot.net/f/n/5?p=Documentation%5COperations%5Cdnceng-operational-responsibilities.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -63,3 +63,8 @@ This approach publishes what amounts to “public surface area” for the shared
|
|||
- A repo level API is explicitly defined and implemented, not just implied
|
||||
- Method exist to directly maintain and update Arcade in each participating repo
|
||||
- Arcade (and its packages) is reasonably serviceable
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5COverview.md) [](https://helix.dot.net/f/n/5?p=Documentation%5COverview.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -46,3 +46,8 @@ The intent is to provide access to a change log which contains all PR’s and th
|
|||
- Is not always categorized by type of change because of automation, e.g. breaking etc (add ML in the future?)
|
||||
- Resource updates and 2nd party services are out of scope for this automation piece
|
||||
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CPolicy%5CArcadeCommunications.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CPolicy%5CArcadeCommunications.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -72,3 +72,8 @@ Time and again differences get worked out when these items occur. To be sure, i
|
|||
* Refrain (where possible) from relying solely on GH comments to find resolution to a particular tricky disagreement. Face-to-face when possible, or at the very least, voice conversations are much higher bandwidth and thus, dramatically more effective.
|
||||
* Initially, leave your own personal 'principles' at the door. Instead work with others to find the right pragmatic next step, but then circle back around and use your principles to help you push for the right longer term solution/approach over time.
|
||||
* Take the opportunity to learn from others. We're all learning together, and the skills required to reconcile differences are very valuable in every venue.
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CPolicy%5CArcadeContributorGuidance.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CPolicy%5CArcadeContributorGuidance.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -134,3 +134,8 @@ darc get-subscriptions --source-repo https://github.com/dotnet/arcade --channel
|
|||
```
|
||||
For each of these subscriptions, call `darc update-subscription --id <GUID id of Subscription> --no-trigger`, updating the channel to `.NET <N or next version> Eng`. Once completed, the above two commands should show no subscriptions, while adjusting the commands for `.NET <N> Eng` should show all the ones from the initial versions of the command.
|
||||
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CPolicy%5CArcadeServicing.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CPolicy%5CArcadeServicing.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -18,4 +18,8 @@ How risky is this change?
|
|||
## Workarounds
|
||||
|
||||
Are there available workarounds for the bug?
|
||||
```
|
||||
```
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CPolicy%5CAskModeTellModeTemplate.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CPolicy%5CAskModeTellModeTemplate.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -30,3 +30,8 @@ When multiple products share the same infrastructure, the most "strict" product
|
|||
There are a few things to keep in mind with servicing:
|
||||
- Shared infra servicing workflow and policies are [found here](ArcadeServicing.md).
|
||||
- Servicing release are basically in perpetual 'Stabilization' mode.
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CPolicy%5CAskTellMode.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CPolicy%5CAskTellMode.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -43,3 +43,8 @@ The criteria for *when* changes can be taken into Arcade are as follows. See fa
|
|||
| Minor, low risk | Very unlikely to have any negative impact |
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CPolicy%5CChangeBar.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CPolicy%5CChangeBar.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -34,3 +34,8 @@ Disruptive changes should be minimal. However, it should be understood that the
|
|||
1. A day later email 'dncpartners' and give them a minimum of a 2 day warning
|
||||
1. Two days later, a 'we're doing this now' email to ‘dncpartners’
|
||||
1. Proactively provide support and/or help as required
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CPolicy%5CChangesPolicy.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CPolicy%5CChangesPolicy.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -50,3 +50,8 @@ It is often challenging to reconcile differences between a given repo build and
|
|||
* In most cases, repo owners can override the Arcade defaults. It should be understood that this will often result in additional risk and cost over time. Regardless, it should continue to be the repo team's 'call' what is done.
|
||||
* Eliminating (or reducing at least) this category is part of the cost of getting the value of a shared infra.
|
||||
* It's hard to do....as it often involves team culture change. The idea though is that the effort (and pain) is worth it.
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CPolicy%5CDefaultsGuidance.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CPolicy%5CDefaultsGuidance.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -97,3 +97,8 @@ Every issue that arises as a result of a rollout must be filed on GitHub in dotn
|
|||
* Every service should have post-deployment checks/scenario tests to ensure the services are up and running taking work. If post-deployment checks/tests fail, changes need to be reverted/fixed via PR in Staging to ensure the deployed services in staging are not broken.
|
||||
* All exploratory / experimental changes need to be done on a dev branch. Any change that is known/expected to temproraily break staging, needs to be communicated to the team (dotnetes@microsoft.com) well in advance and be reasonably timeboxed (case-by-case). This communication should be sent out explaining the period of time in which we expect staging will be down/broken, and put back into a working state by kicking off a build/deploy from master at the appropriate time.
|
||||
* All merges to staging/master need to stop **two days** prior to the day of rollout for e.g. if the rollout is happening on a Wednesday, the last merge to staging/master should happen on EOD Sunday giving us 2 full days for stabilization. Only changes that unblock the staging build would go into staging/master during the stabilization period.
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CPolicy%5CDeploymentPolicy.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CPolicy%5CDeploymentPolicy.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -164,4 +164,8 @@ Positional parameters cause problems for code maintenance, as adding new paramet
|
|||
|
||||
will force this behavior.
|
||||
|
||||
*Note: This rule will check for the usage of positional parameters rather than forcing binding to turn them off.*
|
||||
*Note: This rule will check for the usage of positional parameters rather than forcing binding to turn them off.*
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CPolicy%5CPowershellBestPractices.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CPolicy%5CPowershellBestPractices.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -4,4 +4,8 @@
|
|||
- Every pull request should reference back to a GitHub issue (if the PR is in AzDO, include a link to the GitHub issue in the PR details).
|
||||
- Every rollout must have a GitHub issue to document the change to production.
|
||||
- Every hotfix and deployment rollback must have a GitHub issue to document the change to production.
|
||||
- All dependency additions/changes, such as version upgrades must be approved through team management (e.g. Application Insights)
|
||||
- All dependency additions/changes, such as version upgrades must be approved through team management (e.g. Application Insights)
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CPolicy%5CTeamProcessPolicy.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CPolicy%5CTeamProcessPolicy.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -44,3 +44,8 @@ It would be unreasonable to do nothing other than pay down our technical debt as
|
|||
- There should always be a business priority on the board that actively focuses on reducing technical debt. (right this minute we have two, Helix, and Validation)
|
||||
- We should limit debt reduction business priorities to one at a time. This is to help stay away from “peanut butter” (spreading effort over a wide area) and make significant progress reducing debt in one area. It’s sorta like choosing a credit card balance with the highest interest to pay down first.
|
||||
- There may be times where the business dictates that we don’t have a debt reduction business priority on the board. However, this should be the exception and requires M2 approval as it would go against one of our core principles. For a review, remember to check out our guiding principles.
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CPolicy%5CTechnicalDebtPolicy.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CPolicy%5CTechnicalDebtPolicy.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -27,4 +27,8 @@ If you want to also validate your private build of Arcade using a repository oth
|
|||
1. Provided you have done at least steps 1 and 2 above to create your private build of Arcade and have it published to the "General Testing" channel...
|
||||
2. Create a branch in the repository you wish to validate your private build of Arcade with.
|
||||
3. Using darc, run `update-dependencies` ([update-dependencies documentation](../Darc.md#updating-dependencies-in-your-local-repository)) on your branch to use the build of Arcade you just created in the previous steps.
|
||||
4. Build your project and run the project's unit tests locally, and/or build your branch with your project's Azure DevOps pipeline. Ensure that the build pipeline excutes any tests (unit, integration, scenario, et cetera).
|
||||
4. Build your project and run the project's unit tests locally, and/or build your branch with your project's Azure DevOps pipeline. Ensure that the build pipeline excutes any tests (unit, integration, scenario, et cetera).
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CPolicy%5CTestingMSBuildGuidance.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CPolicy%5CTestingMSBuildGuidance.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -43,3 +43,8 @@ For purposes of this document, 'Toolset' refers to tools which create and/or mod
|
|||
- All toolset updates will be communicated in advance by the engineering services team.
|
||||
- The implication here is that product teams should expect to deal with the toolsets updating on a relatively high cadence. However, this in turn means that the delta will be much smaller for each update.
|
||||
- The latest version principle does not apply to .net runtimes and refpacks when used for compat testing
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CPolicy%5CToolsetPolicy.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CPolicy%5CToolsetPolicy.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -18,3 +18,8 @@ After approximagely two weeks, we will in-place update the existing images as pa
|
|||
|
||||
## Policy for supporting VS 2019 – Private Preview Versions
|
||||
There is currently no Engineering Services support for providing VS private preview queues.
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CPolicy%5CVS2019SupportPolicy.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CPolicy%5CVS2019SupportPolicy.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -65,3 +65,8 @@ The desired product KPI metrics are listed below, with the following fields:
|
|||
| **Missing/Disabled Toolset Input Subscriptions** | Subscriptions | Darc / BarViz | per repo, Per Default Channel (input branch) | Indicates that a branch that applies to a default channel is missing inputs subscriptions for toolset dependencies. A subscription is not missing when dependencies are pinned or when they are tied via CoherentParentDependency attributes to other dependencies. Each dependency should be evaluated based on the assets produced by the last build applied to the input subscriptions. This metric is inexact. It's possible that a dependency missing a subscription now will be produced by the next build applied to a different subscription. | Repository owner determines whether those input dependencies need to be marked as Pinned or whether subscriptions should be created/changed to update automatically. In a release channel, this is not generally needed but should be evaluated on a case-by-case basis. | chcosta<br/><br/>- This is already done in darc, needs to be done in barviz |
|
||||
| **Superfluous Input Subscriptions** | Subscriptions | Darc / BarViz | per repo, Per Default Channel (input branch) | Indicates that a branch that applies to a default channel has subscriptions that may do nothing. Each dependency should be evaluated based on the assets produced by the last build applied to the input subscriptions. This metric is inexact. It's possible that a subscription that looks superfluous now will produce a needed asset in the future. | Repository owner determines whether those subscriptions can be deleted. | chcosta<br/><br/>- This is already done in darc, needs to be done in barviz |
|
||||
| **Conflicting Input Subscriptions** | Subscriptions | Darc / BarViz | per repo, Per Default Channel (input branch) (darc / barviz) | Indicates that a branch that applies to a default channel has subscriptions that produce the same asset. Each dependency should be evaluated based on the assets produced by the last build applied to the input subscriptions. This metric is inexact. It's possible that two currently conflicting subscriptions will not produce conflicting outputs in the future. Because outputs switching between repositories happens infrequently, this metric typically indicates an actual issue. | Repository owner determines whether both subscriptions are needed or whether one should be deleted. | chcosta<br/><br/>- this might already be done |
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CProductKPIs.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CProductKPIs.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -24,4 +24,8 @@ Each attempt of retry details can be viewed from the Tests Details Page.
|
|||
# How to give feedback?
|
||||
Please create a new issue in the [core-eng](https://github.com/dotnet/core-eng) repository.
|
||||
|
||||
[Mission Control]: https://mc.dot.net/#/
|
||||
[Mission Control]: https://mc.dot.net/#/
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CProject-Docs%5CAuto-Retry%20Failures%5CAutoRetryDocumentation.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CProject-Docs%5CAuto-Retry%20Failures%5CAutoRetryDocumentation.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -65,3 +65,8 @@ TestResults
|
|||
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CProject-Docs%5CAuto-Retry%20Failures%5CAutoRetryTelemetry.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CProject-Docs%5CAuto-Retry%20Failures%5CAutoRetryTelemetry.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -61,3 +61,8 @@ In order to support automated configurable retry, we'll need a few changes in th
|
|||
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CProject-Docs%5CAuto-Retry%20Failures%5COverview-Requirements.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CProject-Docs%5CAuto-Retry%20Failures%5COverview-Requirements.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -153,4 +153,8 @@ To access the heartbeats table using Microsoft Azure Storage Explorer, follow th
|
|||
2. Navigate to Helix/HelixStaging subscription.
|
||||
3. Find the storage account helixscripts2 or helixstagescripts2.
|
||||
4. Open the Tables tab.
|
||||
5. Click on heartbeats.
|
||||
5. Click on heartbeats.
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CProject-Docs%5CAutoScaler%5CAutoScalerInvestigateIssues.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CProject-Docs%5CAutoScaler%5CAutoScalerInvestigateIssues.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -131,4 +131,8 @@ Yes. This is currently supported and requires a proxy to be stood up. Please con
|
|||
|
||||
4. Does the blob feed support symbol packages?
|
||||
|
||||
Not yet so for publishing them put them in a flat container until support is added for the symbol package indexing.
|
||||
Not yet so for publishing them put them in a flat container until support is added for the symbol package indexing.
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CProject-Docs%5CBlobFeeds%5CBlob-Feeds-Intro.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CProject-Docs%5CBlobFeeds%5CBlob-Feeds-Intro.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -49,4 +49,8 @@ The above steps are done by using the [Scaler Simulator](#Scaler-Simulator) tool
|
|||
|
||||
**Stage 4:**
|
||||
|
||||
* Instead of using a simulator to determine the max scale, rebalance the max scale on the fly based on the usage by the custom auto-scaler and is able to take in the input of what the total machines allowed are to consider while rebalancing. TBD - Feasibility of implementing this into auto-scaler and ability to test this thoroughly.
|
||||
* Instead of using a simulator to determine the max scale, rebalance the max scale on the fly based on the usage by the custom auto-scaler and is able to take in the input of what the total machines allowed are to consider while rebalancing. TBD - Feasibility of implementing this into auto-scaler and ability to test this thoroughly.
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CProject-Docs%5CCore%20Reduction%5CAutomated_MaxScale_Updates.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CProject-Docs%5CCore%20Reduction%5CAutomated_MaxScale_Updates.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
|
|
@ -147,3 +147,8 @@ duplicates are ignored and not ingested into Kusto.
|
|||
1. Once we are comfortable with the results of the controlled testing, we can
|
||||
start enabling the functionality in product repos for the .NET 5 preview
|
||||
channels.
|
||||
|
||||
|
||||
<!-- Begin Generated Content: Doc Feedback -->
|
||||
<sub>Was this helpful? [](https://helix.dot.net/f/p/5?p=Documentation%5CProject-Docs%5CDependency%20Flow%5Cimproved-dependency-flow.md) [](https://helix.dot.net/f/n/5?p=Documentation%5CProject-Docs%5CDependency%20Flow%5Cimproved-dependency-flow.md)</sub>
|
||||
<!-- End Generated Content-->
|
||||
|
|
|
|||
Некоторые файлы не были показаны из-за слишком большого количества измененных файлов Показать больше
Загрузка…
Ссылка в новой задаче