This path is not anchored in the source project name

426 Views Asked by At

I'm having trouble to migrate WI, that already have been migreted inside the organization between projetcs. Acordding de debug, the sistem is gatting informations from area path and interacion path from when the WI has been created, no from it's atual stauts.

Error:

ERR] System.InvalidOperationException: This path is not anchored in the source project name: OldTeamProjet\Iteraction1\iteraction2 at MigrationTools.Enrichers.TfsNodeStructure.GetNewNodeName(String sourceNodePath, TfsNodeStructureType nodeStructureType) in D:\a\1\s\src\MigrationTools.Clients.AzureDevops.ObjectModel\ProcessorEnrichers\TfsNodeStructure.cs:line 99 at VstsSyncMigrator.Engine.WorkItemMigrationContext.PopulateWorkItem(WorkItemData oldWi, WorkItemData newwit, String destType) in D:\a\1\s\src\VstsSyncMigrator.Core\Execution\MigrationContext\WorkItemMigrationContext.cs:line 383 at VstsSyncMigrator.Engine.WorkItemMigrationContext.ReplayRevisions(List`1 revisionsToMigrate, WorkItemData sourceWorkItem, WorkItemData targetWorkItem) in D:\a\1\s\src\VstsSyncMigrator.Core\Execution\MigrationContext\WorkItemMigrationContext.cs:line 617

the area path should be is SoucerProject/IteractionA

the same is happening in the Iteraction path, is getting a path from creation.

3

There are 3 best solutions below

0
Kym Phillpotts On

Is this because you have the ReplayRevisions set to true, and it is replaying all the revisions (including assignments to Area Paths and Iteration Paths)?

0
kW123 On

You may want to setup AreaMaps and IterationMaps processor

Processors: [{
    "AreaMaps": {
        "Unknown Area": "Desired Area"
    },
    "IterationMaps": {
        "Unknown Iteration in Source": "Desired Iteration"
    }
}]
0
MrHinsh - Martin Hinshelwood On

As per the documentation, you need to add Iteration Maps and Area Maps that adapt the old locations to new ones that are valid in the Target.

Before your migration starts it will validate that all of the Areas and Iterations from the Source work items revisions exist on the Target. Any that do not exist will be flagged in the logs and if you have "StopMigrationOnMissingAreaIterationNodes": true, set the migration will stop just after it outputs a list of the missing nodes.

Our algorithm that converts the Source nodes to Target nodes processes the mappings at that time. This means that any valid mapped nodes will never be caught by the This path is not anchored in the source project message as they are already altered to be valid.

We recently updated the logging for this part of the system to more easily debug both your mappings and to see what they system is doing with the nodes and their current state. You can set "LogLevel": "Debug" to see the details.

To add a mapping, you can follow the documentation with this being the simplest way:

"IterationMaps": {
  "WorkItemMovedFromProjectName\\\\Iteration 1": "TargetProject\\Sprint 1",
},
"AreaMaps": {
   "WorkItemMovedFromProjectName\\\\Team 2": "TargetProject\\ProductA\\Team 2",
}

Or you can use regular expressions to match the missing area or iteration paths:

"IterationMaps": {
  "^OriginalProject\\\\Path1(?=\\\\Sprint 2022)": "TargetProject\\AnotherPath\\NewTeam",
  "^OriginalProject\\\\Path1(?=\\\\Sprint 2020)": "TargetProject\\AnotherPath\\Archives\\Sprints 2020",
  "^OriginalProject\\\\Path2": "TargetProject\\YetAnotherPath\\Path2",
},
"AreaMaps": {
  "^OriginalProject\\\\(DescopeThis|DescopeThat)": "TargetProject\\Archive\\Descoped\\",
  "^OriginalProject\\\\(?!DescopeThis|DescopeThat)": "TargetProject\\NewArea\\",
}

Regular expressions are much more difficult to build and debug so it is a good idea to use a regular expression tester to check that you are matching the right things.

NOTE: You need \\ to escape a \ the pattern, and \\ to escape a \ in JSON. Therefor on the left of the match you need 4 \ to represent the \\ for the pattern and only 2 \ in the match

image

You can find this discussed on the Azure DevOps Migration Project