Merge branch 'MicrosoftDocs:main' into update-docker-agent-pipeline

Author: squassina

docs/artifacts/concepts/media/allow-external-versions.png

@@ -1,9 +1,9 @@
 ---
 title: Configure upstream behavior
-description: Allow or block the consumption of package versions from public registries.
+description: How to allow external package versions.
 ms.technology: devops-artifacts
 ms.topic: conceptual
-ms.date: 02/23/2022
+ms.date: 05/26/2022
 ms.author: rabououn
 author: ramiMSFT
 monikerRange: '<= azure-devops'
@@ -13,15 +13,15 @@ monikerRange: '<= azure-devops'
 
 [!INCLUDE [version-lt-eq-azure-devops](../../includes/version-lt-eq-azure-devops.md)]
 
-Upstream sources enables developers to use a single feed to publish and consume packages from Artifact feeds and public registries such as NuGet.org or npmjs.com. To set up upstream sources for your feed, check the box to **include packages from common public sources**. This will allow your feed to use packages from the common public registries.
+With upstream sources, developers can use a single feed to publish and consume packages from Artifact feeds and public registries such as NuGet.org or npmjs.com. To set up upstream sources for your feed, check the box to **include packages from common public sources**. This will allow your feed to use packages from the common public registries.
 
 :::image type="content" source="media/include-upstream-sources.png" alt-text="Include packages from common public sources checkbox":::
 
 Previously, Artifact feeds combined a list of available package versions from the feed and all the upstream sources.
 
 :::image type="content" source="media/previous-behavior.svg" alt-text="Previous upstream sources behavior":::
 
-Upstream behavior is a feature that enables developers to choose if they want to consume externally-sourced package versions. Upstream behavior dictates which packages will be made available from the public registries for individual packages.
+Upstream behavior is a feature that enables developers to choose if they want to consume externally sourced package versions. Upstream behavior dictates which packages will be made available from the public registries for individual packages.
 
 When the upstream behavior is enabled, when a package is published to your Azure Artifacts feed, any version from the public registry will be blocked and not made available for download.
 
@@ -38,7 +38,7 @@ The next section shows a few common scenarios where the upstream behavior is tri
 
 ## Public versions will be blocked
 
-- **Private package version made public**: in this scenario, a team has a private package that was made public. The upstream behavior in this case will be triggered to block any new public versions (untrusted packages). 
+- **Private package version made public**: in this scenario, a team has a private package that was made public. The upstream behavior in this case will be triggered to block any new public versions (untrusted packages).
 
     :::image type="content" source="media\internal-to-public.svg" alt-text="Internal package version made public":::
 
@@ -49,7 +49,7 @@ The next section shows a few common scenarios where the upstream behavior is tri
 ## Public versions will not be blocked
 
 - **All packages are private**: if all existing packages are private and the team won't be consuming any public packages, the new upstream behavior will have no effect on the team's workflow in this scenario.
-    
+
     :::image type="content" source="media\only-private-packages.svg" alt-text="private packages only":::
 
 - **All packages are public**: if all the packages consumed are public, whether it's from the public registry or any other open-source repositories, the new upstream behavior will have no effect on the team's workflow in this scenario.
@@ -63,11 +63,17 @@ The next section shows a few common scenarios where the upstream behavior is tri
 ## Allow external versions
 
 > [!NOTE]
-> Only feed owners are allowed to configure the upstream behavior. See [Feed permissions](../feeds/feed-permissions.md) for more details.
+> You must be a feed **Owner** or a feed **Administrator** to allow externally sourced versions. See [Feed permissions](../feeds/feed-permissions.md) for more details.
+
+1. Select **Artifacts**, and then select your feed.
+
+1. Select your package, and then select the ellipsis button for more options. Select **Allow externally-sourced versions**.
 
-To configure the new upstream behavior, select a package from within your feed then select the toggle button to **Allow external sourced versions**.
+    :::image type="content" source="media\external-versions.png" alt-text="A screenshot showing how to set up external versions.":::
 
-:::image type="content" source="media\allow-external-sourced-versions.png" alt-text="Allow external sourced versions toggle button":::
+1. Select the toggle button to allow external versions. Select **Close** when you're done.
+
+    :::image type="content" source="media\allow-external-versions.png" alt-text="A screenshot showing how to allow external versions.":::
 
 ## Allow external versions using the REST API
 
@@ -77,7 +83,7 @@ Aside from using the feed's user interface, you can also configure the upstream
 
 - [Get upstreaming behavior](/rest/api/azure/devops/artifactspackagetypes/nuget/get-upstreaming-behavior)
 - [Set upstreaming behavior](/rest/api/azure/devops/artifactspackagetypes/nuget/set-upstreaming-behavior)
- 
+
 #### [npm](#tab/npm/)
 
 - [Get upstreaming behavior](/rest/api/azure/devops/artifactspackagetypes/npm/get-package-upstreaming-behavior)
@@ -95,12 +101,11 @@ Aside from using the feed's user interface, you can also configure the upstream
 - [Get upstreaming behavior](/rest/api/azure/devops/artifactspackagetypes/maven/get-upstreaming-behavior)
 - [Set upstreaming behavior](/rest/api/azure/devops/artifactspackagetypes/maven/set-upstreaming-behavior)
 
-* * * 
+* * *
 
 ## Allow external versions with PowerShell
 
-To successfully execute the next steps in this section, you will need to create a personal access token with packaging **Read, write, & manage** permissions. See [Use personal access tokens](../../organizations/accounts/use-personal-access-tokens-to-authenticate.md) to learn how to create your personal access token. 
-
+To successfully execute the next steps in this section, you will need to [create a personal access token](../../organizations/accounts/use-personal-access-tokens-to-authenticate.md#create-a-pat) with **Packaging** > **Read, write, & manage** permissions.
 
 :::image type="content" source="media\packaging-permissions.png" alt-text="select packaging permissions":::
 
@@ -116,7 +121,6 @@ The following commands will convert your personal access token to baser64 encode
 $token = [Convert]::ToBase64String(([Text.Encoding]::ASCII.GetBytes("username:$env:PatVar")))
 $headers = @{
     Authorization = "Basic $token"
-}
 ```
 
 Invoking the REST method requires an endpoint url. Enter your `OrganizationName`, `ProjectName`, `FeedName`, `Protocol`, and your `PackageName` to construct the `$Url` variable. (Project-scoped feed example: /pkgs.dev.azure.com/MyOrg/MyProject/_apis/packaging/feeds/MyFeed/nuget/packages/Myapp1.0.nupkg/upstreaming?api-version=6.1-preview.1)
@@ -133,8 +137,6 @@ $url = "https://pkgs.dev.azure.com/{OrganizationName}/{ProjectName}/_apis/packag
 $url = "https://pkgs.dev.azure.com/{OrganizationName}/_apis/packaging/feeds/{FeedName}/{Protocol}/packages/{PackageName}/upstreaming?api-version=6.1-preview.1"
 ```
 
-Now that we have both the header and the endpoint URL set up, we can start sending HTTP requests to get, set, and clear upstreaming for any specific package.
-
 ### Get upstreaming behavior
 
 Run the following command to retrieve the upstream behavior state of your package. `$url` and `$headers` are the same variables we used in the previous section.
@@ -153,6 +155,9 @@ $body = '{"versionsFromExternalUpstreams": "AllowExternalVersions"}'
 Invoke-RestMethod -Uri $url -Headers $headers -Body $body -Method Patch -ContentType "application/json"
 ```
 
+> [!NOTE]
+> In some cases, setting up the upstream behavior can take time to propagate across the service. If your package is not available after updating the settings, please allow up to 3 hours for the new settings to take effect.
+
 ### Clear upstreaming behavior
 
 To clear the upstream behavior for your package, run the following commands to set `versionsFromExternalUpstreams` to `Auto` and query the REST API.
@@ -163,9 +168,6 @@ $body = '{"versionsFromExternalUpstreams": "Auto"}'
 Invoke-RestMethod -Uri $url -Headers $headers -Body $body -Method Patch -ContentType "application/json"
 ```
 
-> [!NOTE]
-> In some cases, configuring the upstream behavior can take time to propagate across the service. If your package is not available after updating the settings, please allow up to 3 hours for the new settings to take effect.
-
 ## Related articles
 
 - [Understand upstream sources](upstream-sources.md)

docs/artifacts/concepts/media/external-versions.png

@@ -352,7 +352,8 @@ The following table describes fields associated with links and attachments. Most
    :::column span="3":::
    When included as a column option in a backlog or query results list, the **Title** of the parent work item is displayed. Internally, the system stores the ID of the work item within an Integer field. 
    > [!NOTE]
-   > The **Parent** field is available from Azure DevOps Server 2020 and later versions. You can't specify this field within a query clause. 
+   > The **Parent** field is available from Azure DevOps Server 2020 and later versions. You can't specify this field within a query clause.   
+     
    Reference Name=System.Parent, Data type=Integer
    :::column-end:::
    :::column span="1":::

docs/artifacts/concepts/upstream-behavior.md

@@ -115,11 +115,11 @@ The following table describes the fields that you can use to plan and prioritize
    **Blocked**
    :::column-end:::
    :::column span="2":::
-   Indicates that no further work can be performed on the work item. If an issue has been opened to track a blocking problem, a link should be made to the issue.
+      Indicates that no further work can be performed on the work item. If an issue has been opened to track a blocking problem, a link should be made to the issue.
+      - For the Scrum process, task work items: You can specify **Yes** or clear the field. 
+      - For the CMMI process work items: You can specify **Yes** or **No**.
 
-   You can specify **Yes** or **No**.
-
-   Reference name=Microsoft.VSTS.CMMI.Blocked, Data type=String
+     Reference name=Microsoft.VSTS.CMMI.Blocked, Data type=String
    :::column-end:::     
    :::column span="1":::
    Bug, Change Request, Requirement, Risk, Task (CMMI, Scrum)

docs/boards/queries/linking-attachments.md

@@ -512,7 +512,11 @@ You can use date fields to filter your queries. Some of these fields are populat
     :::column-end:::
     :::column span="2":::
       The date and time when the schedule indicates that the task will start.
-   Reference name=Microsoft.VSTS.Scheduling.StartDate, Data type=DateTime
+      ::: moniker range="azure-devops"
+      > [!NOTE]   
+      > [Delivery Plans](../plans/review-team-plans.md) uses the **Start Date** and **Target Date** to show the span of Features, Epics, and other portfolio backlog items. 
+      ::: moniker-end
+      Reference name=Microsoft.VSTS.Scheduling.StartDate, Data type=DateTime
    :::column-end:::
    :::column span="1":::
       Epic, Feature, Requirement, Task, Test Plan, User Story
@@ -535,15 +539,15 @@ You can use date fields to filter your queries. Some of these fields are populat
       Target Date
     :::column-end:::
     :::column span="2":::
-      The date by which a feature or work item is to be completed.  
+      The date by which a feature, work item, or issue is to be completed or resolved.  
       ::: moniker range="azure-devops"
       > [!NOTE]   
-      > [Delivery Plans](../plans/review-team-plans.md) uses the Start Date and Target Date to show the span of Features, Epics, and other portfolio backlog items. 
+      > [Delivery Plans](../plans/review-team-plans.md) uses the **Start Date** and **Target Date** to show the span of Features, Epics, and other portfolio backlog items. 
       ::: moniker-end
       Reference name=Microsoft.VSTS.Scheduling.TargetDate, Data type=DateTime
    :::column-end:::
    :::column span="1":::
-      Epic, Feature
+      Epic, Feature 
    :::column-end:::
 :::row-end:::
 

docs/boards/queries/planning-ranking-priorities.md

@@ -23,12 +23,14 @@ This guidance explains how to automatically build C++ projects for Windows.
 This example shows how to build a C++ project. To start, import (into Azure Repos or TFS) or fork (into GitHub) this repo:
 
 ```
-https://github.com/adventworks/cpp-sample
+https://github.com/MicrosoftDocs/pipelines-cpp
 ```
 
 ::: moniker range="< azure-devops"
+
 > [!NOTE]
 > This scenario works on TFS, but some of the following instructions might not exactly match the version of TFS that you are using. Also, you'll need to set up a self-hosted agent, possibly also installing software. If you are a new user, you might have a better learning experience by trying this procedure out first using a free Azure DevOps organization. Then change the selector in the upper-left corner of this page from Team Foundation Server to **Azure DevOps**.
+
 ::: moniker-end
 
 * After you have the sample code in your own repository, create a pipeline using the instructions in [Create your first pipeline](../../create-first-pipeline.md) and select the **.NET Desktop** template. This automatically adds the tasks required to build the code in the sample repository.
@@ -45,13 +47,13 @@ It is often required to build your app in multiple configurations. The following
 
    * `BuildPlatform` = `x86, x64`
 
-2. Select **Tasks** and click on the **agent job**. From the **Execution plan** section, select **Multi-configuration** to change the options for the job:
+1. Select **Tasks** and click on the **agent job**. From the **Execution plan** section, select **Multi-configuration** to change the options for the job:
 
    * Specify **Multipliers:** `BuildConfiguration, BuildPlatform`
 
    * Specify **Maximum number of agents**
 
-3. Select **Parallel** if you have multiple build agents and want to build your configuration/platform pairings in parallel.
+1. Select **Parallel** if you have multiple build agents and want to build your configuration/platform pairings in parallel.
 
 ## Copy output
 
@@ -60,4 +62,3 @@ To copy the results of the build to Azure Pipelines, perform these steps:
 1. Click the [Copy Files task](../../tasks/utility/copy-files.md). Specify the following arguments:
 
    * **Contents:** `**\$(BuildConfiguration)\**\?(*.exe|*.dll|*.pdb)`
-

docs/boards/queries/query-by-date-or-current-iteration.md

@@ -3,7 +3,6 @@ title:  Analytics widgets
 titleSuffix: Azure DevOps
 description: Learn about the widgets based on Analytics data that you can add to a dashboard in Azure DevOps.
 ms.technology: devops-analytics
-ms.reviewer: romik
 ms.author: kaelli
 author: KathrynEE
 ms.topic: conceptual

docs/pipelines/apps/windows/cpp.md

@@ -2,8 +2,7 @@
 title: Explore the OData metadata for Analytics 
 titleSuffix: Azure DevOps  
 description: Learn about the entity model OData metadata defined for Analytics in Azure DevOps.
-ms.technology: devops-analytics
-ms.reviewer: angurusw
+ms.technology: devops-analytics 
 ms.author: kaelli
 author: KathrynEE
 ms.topic: tutorial

docs/report/dashboards/analytics-widgets.md

@@ -8,18 +8,24 @@ ms.author: kaelli
 author: KathrynEE
 ms.topic: conceptual
 monikerRange: '>= azure-devops-2019'
-ms.date: 09/30/2020
+ms.date: 05/25/2022
 ---
 
 # Data model for Analytics  
 
 [!INCLUDE [version-gt-eq-2019](../../includes/version-gt-eq-2019.md)]
 
-Analytics data model for Azure DevOps consists of entity sets, whose members (entities) contain properties that can be filtered, aggregated, and summarized. Additionally, they contain [navigation properties](https://www.odata.org/getting-started/basic-tutorial/#relationship) that relate entities to one other, providing access to other properties for selecting, filtering, and grouping.
+The Analytics data model for Azure DevOps consists of entity sets, whose members (entities) contain properties that can be filtered, aggregated, and summarized. Additionally, they contain [navigation properties](https://www.odata.org/getting-started/basic-tutorial/#relationship) that relate entities to one other, providing access to other properties for selecting, filtering, and grouping.
 
 [!INCLUDE [temp](../includes/analytics-preview.md)]
 
 
+## Schema namespaces 
+
+The Analytics data model is based on two schema namespaces:
+- `Microsoft.VisualStudio.Services.Analytics.Model` 
+- `Microsoft.VisualStudio.Services.Analytics`. 
+ 
 <a id="entities" />
 
 ## EntityTypes and EntitySets  
@@ -60,11 +66,11 @@ The following **EntitySets** are supported with the indicated API versions. For
 > |----------------------|-------------|------|------|--------------|--------------|
 > |**Area**/<br/>**Areas** |The work item **Area Paths**, with properties for grouping and filtering by area hierarchy. | ✔️|✔️|✔️ | ✔️ |  
 > |**Iteration**/<br/>**Iterations** | The work item **Iteration Paths**, with properties for grouping and filtering by iteration hierarchy.  |✔️|✔️|✔️ | ✔️ |  
-> |**BoardLocation**/<br/>**BoardLocations** |The Kanban board cell locations, as identified by board column, lane, and split, includes historic board settings. For a description of each Kanban board field, see [Workflow and Kanban board fields](../../boards/queries/query-by-workflow-changes.md#workflow-and-kanban-board-fields).| ✔️|✔️|✔️ | ✔️ |  
+> |**BoardLocation**/<br/>**BoardLocations** |The Kanban board cell locations, as identified by board column, swimlane, and split, includes historic board settings. For a description of each Kanban board field, see [Workflow and Kanban board fields](../../boards/queries/query-by-workflow-changes.md#workflow-and-kanban-board-fields).| ✔️|✔️|✔️ | ✔️ |  
 > |**CalendarDate**/<br/>**Dates** | The dates used to filter and group other entities using relationships.  | ✔️|✔️|✔️ | ✔️ |  
-> |**Project**/<br/>**Projects** |All projects defined for an organization. |✔️|✔️|✔️ | ✔️ |  
+> |**Project**/<br/>**Projects** |All projects defined for an organization (cloud) or project collection (on-premises). |✔️|✔️|✔️ | ✔️ |  
 > |**Process**/<br/>**Processes** |Backlog information used to expand or filter work items and work item types. For an example that uses **Processes** to filter a report, see [Requirements tracking sample report](../powerbi/sample-stories-overview.md). |  |✔️|✔️ | ✔️ |  
-> |**Tag**/<br/>**Tags** | All work item tags for each project. For an example that uses **Tags** to filter a report, see [Release burndown sample report](../powerbi/sample-boards-releaseburndown.md). | ✔️|✔️|✔️ |  
+> |**Tag**/<br/>**Tags** | All work item tags for each project. For an example that uses **Tags** to filter a report, see [Release burndown sample report](../powerbi/sample-boards-releaseburndown.md). | ✔️|✔️|✔️ | ✔️ | 
 > |**Team**/<br/>**Teams** | All teams defined for the project. For an example that uses **Teams** to filter a report, see [Add a Team slicer to a Power BI report](../powerbi/sample-boards-teamslicer.md).  | ✔️|✔️|✔️ | ✔️ | 
 > |**User**/<br/>**Users** |User information that is used to expand or filter various work item properties, for example **Assigned To**, **Created By**. | ✔️|✔️|✔️ | ✔️ | 
 > |**WorkItemBoardSnapshot**/<br/>**WorkItemBoardSnapshot** |(Composite) The state of each work item on each calendar date, including Kanban board location, used to generate trend reports.   For a sample report, see [Cumulative Flow Diagram (CFD) sample report](../powerbi/sample-boards-cfd.md). | ✔️|✔️|✔️ | ✔️ |