I met this Jenkins build problem when commit to P4.
ERROR #5001: GUID reference(s) missing from stream websys/TranslationType/questionnaire.QCNXXCVD.Edit/68D7225A-DE63-11EB-AF4C-005056B66BA0.xml; 35551C28-0C38-11EB-A1C8-005056B66BA0
So how can I solve this problem. Would anybody help me?
Thanks.
input by Jack Huser · Aug 26, 2021
This error means that you have some element modified in TrakCare as Site level (or deleted), but the Questionnaire is Region Level. To solve this issue, you should check in TrakCare what GUID is missing:
Tools >> Change Control >> Find GUID
Check which component should have been saved as Region level or has been removed.
Once you have it saves as Region Level you will be able to commit to P4.
I checked in Perforce and it seems the component was deleted on 6 november 2020 with JIRA TC-260035 but recreated on 1st august 2021 with JIRA TC-301371.
So your problem should have been solved.
Regards,Jacques
Related
English is not my first language, and I am a bit rusty, so please bear with me.
When browsing the Sonar analysis for my project, I have the following seemingly incorrect data displayed: the creation date of the issue is not the commit date for this date, and I would like to understand why. It so happens that April 29 at 9:35 is the date of the last analysis on that branch.
My code is managed with git and hosted on GitLab. Sonarqube server is at version 7.9.2.30863.
I made some research and found the following: https://docs.sonarqube.org/latest/user-guide/issues/#header-5.
As far I understand the above page says that all created issues have a creation date equals to the commit date, except if one of the following conditions is true:
first analysis of a project or branch. More on that below. Let me move the rest out of the way first.
When the rule is new in the profile (a brand new rule activated or a rule that was deactivated and is now activated). The quality profile used for this analysis was not modified
When SonarQube has just been upgraded (because rule implementations could be smarter now). I know I did not upgrade the server. However, it is difficult for me to prove that the server was not upgraded by someone else. I checked the logs, and all I can say is that the Sonar Qube server was last restarted on 2021/04/26, so a few days before the first ‘faulty’ analysis. Since I believe that an upgrade would force a restart, I can assume this condition I out of the way too.
When the rule is external. I do not know what an external rule is. It seems to be linked to the configuration found under Administration > General Settings > External analyzers. However, it is all empty, so I believe I use no external analyzer, hence no external rules that are checked during an analysis.
Back to the first condition: ‘first analysis of a project or branch.’. This is now the most plausible explanation since all the other conditions are out of the way.
Sonar does not provide much history for short-lived branches, so I had to check my continuous integration pipelines to find out when the previous analysis was on that branch. I found a successful execution a few weeks ago (2021-04-09). Since it was more than a few days ago, could it be that the results of that analysis were somehow purged and that the analysis that took place on April 29 was somehow a ‘first analysis’ again? How to check that?
Conclusion: I still do not know why the date on that issue(and some others too) is wrong. All 'faulty' issues are located on the same file. I would gladly welcome any help.
Thanks in advance!
Is it possible that the old issue was just merged into the branch you are currently analyzing?
I had a situation like this:
Checkout feature A branch in January 2021, chip away at it slowly
Checkout feature B branch in February 2021 - This one contains the issue merge feature B onto main in March 2021
Complete work on feature A, run sonarqube analysis
Merge in main, which contains feature B, run sonarqube analysis
Issue from feature B is reported as being created today instead of March 2021
If you were to merge Feature A back to main and then run analysis on main, the issue from feature B would have the correct date, but any new issues from feature A would be dated as per the analysis date.
sonarqube-9.3.0.51899
Here's the error I was getting in VS2015: "One or more checked work items failed the transition testing due to invalid field values. Please correct the values and retry the check-in."
I had this when checking in an associated work item and flagging the item as resolved. So
Work item in in progress
Check in with this work item marked as resolved
Work item is updated to ready to test
BUT
the work item can't move into the new state as it needs additional information. In my case TFS is set to assign the bug back to the person that raised it. It was such an old bug that the person raising it had left the company and doesn't exist in TFS - hence the error.
Moral of the story - fix bugs quicker.
In my case, I was forced to do the Associate since I got the error message. When I went into the Work Item in VSTS I manually resolved it and it prompted me to set a required field. Were that required field set, the Resolve from Visual Studio would have worked.
I faced same issue while check in from visual studio.
Change the related work item as associate instead of resolve from visual studio solved my issue.
As a workaround : Create a new task/bug in your VSTS for whichever story. Then assign your check in to that work-item. That's what the error is somewhat saying... Difficult for me to decipher at first, hope this helps others.
You need to determine the task status you have created for your TASK. You should set your task state -- Development or other, You get an error because "state" is "new"
I'm using DevOps 2019 on-prem and I had 1 little update to share.
I created the Bug on the Web Portal and kept it open, added the Ticket Number for the checkin and got the above error.
EASY FIX :
Remove Ticket from Checkin
Close Ticket in Web Portal
Re add Ticket
Checkin
ALL IS GOOD.
I have an infuriating problem that occurred recently.
Whenever I try to add or rename a file in any of the projects in my solution, or even the solution name itself, I get the following:
Error
TF10210: Source control encountered an error during move
operation: Unable to rename
C:\xxxxxxxxvisualstudio.com\xxxxxxxx -
Rigg\src\xxxxxxxx.Rigg.Domain\Area.cs to
C:\xxxxxxxxvisualstudio.com\xxxxxxxx -
Rigg\src\xxxxxxxx.Rigg.Domain\Area2.cs
Specified argument was out of the range of valid values.
Parameter name: pathLength
(I've replaced the names of mine and the client's company with x'es.)
The thing is, up to last Friday I never had this problem, I've been working on the solution for more than 6 months.
I have not renamed or restructured the solution folder recently.
I've tried deleting the solution folder and getting an earlier checkin from before this happened, with no luck.
I do not get the message if I open the solution in VS2013, which leads me to believe the problem is related to VS2010, and maybe doesn't have anything to do with path length. Unfortunately I can't work on the project in VS2013, as it is MVC3.
Any suggestions?
EDIT:
Solved. I changed the solution's mapping, and it worked. Then I changed it back to the original, and it still worked! I have no idea why this happened, but apparently fiddling with the mapping solved it.
Here we have Dynamics AX 2013 R3 CU8 with the same error:
Team Foundation Server nonfatal error
Specified argument was out of the range of valid values.
Parameter name: pathLength
Can you please describe a bit more detailed how you have fixed the error?
We inadvertently broke VS2010 compatibility in our latest update. We rolled out a fix over night. Let me know is you still hit it. Sorry for the trouble!
I'm trying to change the work flow for bugs in TFS 2013.
The default is New, Approved, Committed, Done, Removed. I would like to change this to New, Committed, Ready For Testing, Done, Rejected.
I installed Power Tools 2013 to do this, so I'm opening the bug WIT from the server and using the Workflow type. However, anytime I even rename an existing state and save, it's causing this behaviour where if I change a bug to the state I created/edited it automatically removes it from the backlog. What am I doing wrong here??
Any help would be greatly appreciated, thanks.
For anyone else who comes across the same issue, I worked out what was wrong. I had to import the Bug.xml and the ProcessConfiguration.xml. I had to add a state type for the states I changed/added to the ProcessConfig before I imported it.
You need to import the WITD (Work Item Type Definition) XML into you project using the witadmin command line application.
For example:
witadmin importwitd /f:Bug.xml /p:MyProject /collection:http://tfs:8080/tfs/DefaultCollection
Using log4J we are writing in a log file and when I open the log file , I see the content updated in the file, but when I see the properties listed , the last modified time is not updated. I am not sure its a windows issue or Log4J issue. This machine is windows7 Enterprise edition.
Did anyone face this kind of issue ?
What should be the approach so that we can see the correct last modified time ?
Does Log4J provide synch/flush kind of feature?
I will be greatful if you can comment.
Regards - JE