I've tried to get this to work a few times but running into the same problem.
A number of workitems are failing with the following error:
OH-Connector-0143: Target system does not contain value : Resolved for field: State for entityType: Task
I've replaced the source projects WIT with the standard versions and I've tried to change the status on the work items referred to. All are Task type work items and have had state set to Resolved at some point although I have checked all failed items and none currently set to that state.
We are also seeing another failure message which I have assumed is caused by the above error which is:
OpsHub-012010: Processing blocked - earlier event(s) for entity 6960 have to be processed first.
Additionally, no source has migrated. It is my assumption that this is because of the work item failures?
The reason the failure is because the history of those workitems has already been persisted. It cannot be changed. You can update the current value of those WITs with an available state, but the historic revisions will remain the same.
OpsHub's Migration Tool migrates your entire history. Therefore, while processing the revisions where the State was 'Resolved', the issue is encountered.
And yes, the 'processing blocked' errors are because of the above error and the SCM migration will not start until the WIT is done due to linkage dependency.
Related
I am not sure if this is a defect, or expected behavior, but I find when I update a TaskGroup or a Library in TFS, these changes do not always cascade down to each consumer. The refresh to consumer does happen sometimes, but it's hit or miss at best.
If these Task Groups and Library features don't cascade down when you update them then what is the point?
How did you use the Task Group/Library (Variable Group)?
Based on my test on TFS 2017 Update 3 (Version 15.117.27414.0), the Task Group/Library (Variable Group) works as expected.
That means once you have updated the Task Group/Library (Variable Group), then the corresponding changes and values will also reflect to the build/release which using the specific Task Group/Library.
For example, once I updated the value of the variables (Library-variable group), then the value also changed in the next release. Reference below screenshot.
More information please refer to Variable groups for builds and releases.
Using TFS 2013, we don't seem to be able to use the History section for Work Items because it just gets clogged full of the following statements:
TFSBuild (2 days ago)
The Fixed In field was updated as part of associating work items with the build.
This is where I assume we're supposed to write history such as "tested the bug, re-opening since the following error is still occurring...". We've been putting all comments like this in the Description field though because they get lost in the history section with all the Fixed In messages.
It seems like every single build produces this Fixed In message, although it might be limited to the product backlog item - it doesn't seem consistent. Some items have about 50 of these entries and some have none.
My expectation was that these messages would only show up on the work items that the programmers referred to when committing the code. Are they possibly doing something strange when committing the code? Or is there some sort of procedure I can do to stop these messages from filling up the history entry? Thanks!
You can set "Associate Changesets and Work Items" option to "False" in your build definition to stop updating the associate work items when a build is completed.
Work items will be updated when the build with associated changeset completes and "Associate Changesets and Work Items" is set to "True". Your problem looks the same as this question:
https://serverfault.com/questions/40028/tfs-stop-team-build-process-has-updated-the-fixed-in-field-messages.
It was caused by the build wasn't completely succeed. You can refer to it to see if it can help you resolve the problem.
For more detailed information about Associate Changesets and Work Items, you can read this blog:
http://www.andygeldman.com/index.php/2011/10/ever-expanding-associated-changesets-and-work-items/comment-page-1/
In TFS 2012, I was able to use XAML based on this to customise our workflow to compare the number of warnings in the current build, to previous builds. (I have seen similar code elsewhere to check that code coverage has not gone down, etc).
In TFS 2013, there appears to be no way to retrieve results from previous builds as the BuildDetail type is no longer visible. Specifically, I got the following error:
The build process failed validation. Details: Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error: Compiler error(s) encountered processing expression "Microsoft.TeamFoundation.Build.Client.InformationNodeConverters.GetBuildWarnings(BuildDetail).Count". 'Microsoft.TeamFoundation.Build.Client.BuildDetail' is not accessible in this context because it is 'Friend'. Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error: Compiler error(s) encountered processing expression "BuildDetail.BuildServer.GetBuild(BuildDetail.BuildDefinition.LastGoodBuildUri)". 'Microsoft.TeamFoundation.Build.Client.BuildDetail' is not accessible in this context because it is 'Friend'. 'Microsoft.TeamFoundation.Build.Client.BuildDetail' is not accessible in this context because it is 'Friend'.
Is there any way, in TFS 2013, to access details of previous builds, that BuildDetail.BuildServer.GetBuild provided in TFS 2012? I cannot find any samples on the web that aren't using the old method.
The TFS Product Team have dramatically simplified the build as 90% of people out there either do not customise or want some simple customisation that can be done in PowerShell. If you want to have BuildDetail you can get it by using the "GetBuildDetail" activity that is included in the build.
After further investigation, it turns out that the TFS Build Extensions provide a GetLastGoodBuild activity, which appears to do what I need.
While adding many 1000s of files to the online version of TFS at visualstudio.com, I have started getting "The decryption operation failed, see inner exception".
I cannot even resolve or check in a single file (from the new batch of 34,000+ additions).
As the message is displayed in the pending changes window, there is no way that I can see to get more details (or view the inner exception).
1) Is this a TFS, VS 2013 or network issue
2) How can I get at the more detail information of the error in VS 2013?
Before anyone suggests "turn it off and on again", rebooting has not made any difference to the problem.
Also switching the advanced workspace location from "local" to "server" made no difference.
Have we just hit a wall in TFS?
*Note: It does not effect checkin to other folders outside of the new additions
It appears that the online TFS service provided through visualstudio.com has some limitations.
The solution to the problem above was to undo the 34,000+ item check and add them in smaller batches. Up to around 10,000 files at a time seems to behave itself.
Update:
I have just had the same error on a fresh machine install, where I tried to pull down my entire TFS repository in one go. Again pulling them down piece-by-piece avoided the error
We have upgraded to TFS 2012 (from 2010) and are having a few issues with our custom process templates.
On each project we get this message when navigating to the Backlogs page on the web access site.
This feature cannot be used until you configure it for this team project.
Clicking configure and running the automatic configuration page returns the following errors for projects which have had their process templates customized when they were on 2010.
[Warning] TF400609: Cannot add the action 'Microsoft.VSTS.Actions.StartWork' to the work item type 'Task' because the state 'New' does not exist.
[Warning] TF400609: Cannot add the action 'Microsoft.VSTS.Actions.StopWork' to the work item type 'Task' because the state 'New' does not exist.
[Error] TF400654: Unable to configure Planning Tools. The following element contains an error: RequirementBacklog/States. TF400587: This element defines the states for work items that appear on your backlog. Each state must exist in at least one of the work item types belong to category defined in: 'RequirementBacklog/States'. The following state does not exist in any of the work item types: Active, Resolved.
[Error] TF400654: Unable to configure Planning Tools. The following element contains an error: BugWorkItems/BugWorkItems. TF400506: This element defines the states for work items that represent Bugs or Defects. Each state must exist in at least one of the work item types that are defined in: BugWorkItems. The following states do not exist in any of the work item types: Active, Resolved.
[Error] TF400654: Unable to configure Planning Tools. The following element contains an error: BugWorkItems/BugWorkItems. TF400507: Each work item type must support an initial state value that matches one of the states defined in: BugWorkItems. The following work item types have initial states that do not include any states defined in the bug state configuration: Bug.
Other projects which were not customized do not return the errors and they upgrade with no problems.
Reading around the web I can see the problem is because of the custom templates, but their seems to be a few different options for fixing this. Has anyone had any experience of this and what would you suggest doing to fix it?
Have you checked the ALM Rangers' Upgrade guide? There is an appendix (and tool) on this topic.
There are some guides on MSDN, basically, you have customised your template away from the TFS understands. For example, for it to be MSF Agile, you have "User Stories", if you have "Requirements" you're CMMI.
I upgraded our heavily customised template based on these guides:
Update a customized process template to access new features
New features enabled for Team Web Access
This isn't really a good fit question for SO, as it is quite open ended and the list of things could be quite broad.
That said, if you take your current work items and add what it is looking for, perform the upgrade, then remove them and update the configuration after wards it should work OK.
For example, add a "New" state to the start of your tasks upgrade, then edit the process config after upgrade to say your equivalent of "New" is the Start Work Trigger.