Create Epic work item type as Service or product #6782
Conversation
praveenkuttappan
added
the
Central-EngSys
praveenkuttappan
requested review from
konrad-jamrozik,
weshaggard and
benbp
as code owners
|
The following pipelines have been queued for testing: |
|
The following pipelines have been queued for testing: |
|
The following pipelines have been queued for testing: |
|
The following pipelines have been queued for testing: |
|
The following pipelines have been queued for testing: |
|
The following pipelines have been queued for testing: |
| return $serviceParent | ||
| } | ||
|
|
||
| $fields = @() | ||
| $fields += "`"PackageDisplayName=`"" | ||
| $fields += "`"ServiceName=${serviceName}`"" | ||
| $fields += "`"Custom.EpicType=Service`"" |
There was a problem hiding this comment.
Do we need to care about Sub-Service type or Component type?
There was a problem hiding this comment.
We create another Epic Item as child of Service Epic for the product. I am assuming that's what used currently for subservice name as well.
There was a problem hiding this comment.
We are managing subservice as another EPIC. Same as previously done before
There was a problem hiding this comment.
It is fine if it is another Epic but does this automation need to handle those as well?
There was a problem hiding this comment.
Prepare release scrip is already handling it by creating a child under Service WI and then creating individual language package items under this subservice/product WI.
| @@ -218,6 +270,7 @@ function FindPackageWorkItem($lang, $packageName, $version, $outputCommand = $tr | |||
| $fields += "System.State" | |||
| $fields += "System.AssignedTo" | |||
| $fields += "System.Parent" | |||
| $fields += "System.Tags" | |||
There was a problem hiding this comment.
What are we getting from the Tags? Is that only to filter out the tests? If so we might want to consider other potential ways to filter these out, like perhaps having some way to close them all so they don't show up in the queries.
There was a problem hiding this comment.
This is to avoid showing up work items created from release planner app in dev and PPE.
There was a problem hiding this comment.
Are tags the best way of doing this? These will also start to show up in other query or dashboards that folks might be using directly in DevOps. Can we instead have something that goes in and closes all the dev and PPE created items?
There was a problem hiding this comment.
Yes, we can mark them as closed by automation pipeline. I will discuss with @maririos and come up with a plan. In the meanwhile, I think we should include current changes so work items created by prepare release script won't attach package WI to incorrect service and product.
Sync eng/common directory with azure-sdk-tools for PR Azure/azure-sdk-tools#6782 See [eng/common workflow](https://github.com/Azure/azure-sdk-tools/blob/main/eng/common/README.md#workflow) --------- Co-authored-by: praveenkuttappan <[email protected]>
Sync eng/common directory with azure-sdk-tools for PR Azure/azure-sdk-tools#6782 See [eng/common workflow](https://github.com/Azure/azure-sdk-tools/blob/main/eng/common/README.md#workflow) --------- Co-authored-by: praveenkuttappan <[email protected]>
Epic type is not set when prepare release script creates a work item for a new service or product. This change is to set epic type as service or product so it aligns with new dashboard changes for service and product work items.