I'm migrating a large amount of projects from a on premise tfs2010 to vso, nearly all of them was able to migrate without any problems, but a few are creating errors. I am using Opshub Integration Manager Framework-OVSMU-V1.2.0.000.
1.
OH-TFS-Connector-0054: Test Step Id cannot be empty and It must be a valid number. Please check the Mapping and add valid mapping for the Test Step Id.
The most common error. This error is also described in opshub-visual-studio-online-migration-utility-test-cases-failing, but has yet to receive an accepted answer. As mentioned in this post the cause if the problem might be Shared Steps, so I tried removing one from a test case, and that made it pass in the migration utility. Unfortunately I need those test cases and it is not feasible for me to just delete them.
2.
OH-TFS-Connector-0051: Operation failed getCollectionMetaData. Server Error : TF201063: Adding a Test Case link to work item 18374 would result in a circular relationship. To create this link, evaluate the existing links, and remove one of the other links in the cycle.
After inspecting the Work Items that causes the error and concluding that there is no links, and no clear circular reference, not even a Shared Step linking to work item 18374. Upon further inspection I noticed that work item 18374 doesn't even exist.
Any help would be much appreciated.
OH-TFS-Connector-0054: Test Step Id cannot be empty and It must be a valid number. Please check the Mapping and add valid mapping for the Test Step Id.
This issue is addressed in latest release of OVSMU (1.3.0.000). You can download from
https://visualstudiogallery.msdn.microsoft.com/28a90a17-d00c-4660-b7ae-42d58315ccf2
OH-TFS-Connector-0051: Operation failed getCollectionMetaData. Server Error : TF201063: Adding a Test Case link to work item 18374 would result in a circular relationship.
This issue is scheduled for next release which will be out shortly. Check Visual Studio Gallery for further updates.
Thanks.
Related
We had some projects deleted in Azure DevOps and we restored them, however all the widgets in the dashboard are broken. Is there a way to recover them or do we have to rebuild?
The dashboard does report across 3 projects, all of which were deleted then restored.
I receive a message about a / in a project title, but the project title I see does not have a /.
I have searched the User Guide and cannot seem to find the answer on this or one that explains the error message.
enter image description here
#wadezhou Cloud service. The error message says 'Widget error 400: The query configuration is invalid or number of work items returned exceeds the size limit.' (link above) I don't believe it is due to work items because I don't believe any work items have been added (these projects are just a proof of concept) and it was working before they were deleted. I have not tried to create a new widget - I will try that and see if it works and let you know. I'm not sure to tell if it's TFVC or git? It is Agile.
Here is a screenshot of the error where it mentions the / (when I go into the query):
error detailing /
When I try to create new widgets on the dashboard one works and one doesn't:
enter image description here
From what I can tell - it seems Git is the default type, and I have not changed it from whatever default would be.
I need some help, I'm starting with this automation stuff, I like it but I'm still learning, recently I create a test case that basically is, going to a certain page and click on a button to upgrade the account on an specific sale, so I did that but when I got my PR reviewed and devops ask me if I can add an assertion.
So, this code is on the spec file not on the page objects file, so the devops mean I have to create the code on the page object file and then call it on the spec file???? any tip would be great and thanks!
You can do it either way. You can write the assertion in the spec file, or write the assertion in the page objects file and call it from the specs file. If the latter is your framework's code convention, you may want to do it that way for consistency, but either way should work.
I am getting error whenever i recompile my workflow package.
to solve this error i have to bounce the server which is used among no of users.
if it is possible to get separate server so i can bounce and test it without disturbing DBA/system admin.
Aha; it seems that you posted two questions for the same problem; this is another one.
As of your problem: Oracle says this:
ORA-06508: PL/SQL: could not find program unit being called: "APPS.ATL_OARR_PCKG" '
in 'PLSQL' API 'ATL_OARR_PCKG.GET_CUSTOM_NOTIF'
Why wouldn't you make sure that all objects, referenced by your package, exist before you compile it? What benefit do you see in having an invalid package? You can't use it anyway, you can't test it, you can't do anything.
Therefore, having yet another server most probably won't fix that problem, because I suspect that missing package (if that's what ATL_OARR_PCKG is) won't automagically appear on the new server.
When trying to update a service reference in a class library (VS2013), i get the following error.
"The configuration for the service reference could not be updated due to the following issue: An error occurred creating the configuration section handler for system.serviceModel/bindings: AssemblyResolveEvent handlers cannot return Assemblies loaded for reflection only."
This same error happens when i try to delete the reference as well.
Any help in sorting would be greatly appreciated.
I've had the same issue after updating to VS2013 Update 2.
I've solved the issue by temporarily cutting the whole system.serviceModel section out of web.config, pasting it somewhere else like Notepad. Then, I've saved the web.config without the service model section. Then, I was able to update the service reference successfully. After updating the service reference, I've pasted the service model section back to web.config and it worked successfully.
I was able to work around this similarly to Can by temporarily removing the extensions element of the system.serviceModel section and any associated extension elements. In my case the extensions were Azure Service Bus extensions.
In my experience it has been as simple as to delete the service reference and re-adding it. For example, last time it happened it was on a WebService (not WCF, the old one), and the error started appearing after we changed one of the classes that was being sent as a return from different routines/functions. After adding one more property to the class, it started going crazy and prompting errors everywhere.
Just a simple Delete and re-Add Service Reference did the trick.
Only need to one time remove <system.serviceModel> section from web.config. After Create first service refrence , this section rebuild by Vs.
I dont know why, but JBehave does not take in consideration failures in the given stories. If there is a failure in a givenstory, it will not perform the rest of the steps of that story, but it will execute the rest of the given stories. Here is a example:
GivenStories: stories/web/pmv/Story1.story,
stories/web/pmv/Story2.story,
stories/web/pmv/Story3.story,
stories/web/pmv/Story4.story,
stories/web/pmv/Story5.story
When the user do something
Then something happens
For instance, if the Story2.story fails, I was expecting that the rest of the given stories and the last 2 steps were not executed. But they are.
Anyone knows why is that?
How can I fail all stories if one single step or story fails?
I noticed as well that the reports statistics just reflect the last given story and the following steps. Is this correct? Why?
I have the following configuration:
configuredEmbedder().embedderControls()
.doGenerateViewAfterStories(true)
.doIgnoreFailureInStories(false)
.doIgnoreFailureInView(false)
.useThreads(2)
.useStoryTimeoutInSecs(60);
MostUsefulConfiguration:
.useStoryControls(
new StoryControls()
.doDryRun(false)
.doSkipScenariosAfterFailure(true)
.doResetStateBeforeScenario(false))
When i added the config doResetStateBeforeScenario(false), the following steps after the failure, even the ones inside the givestories were not performed. But in yet, the statistics show no error, because it was not last given story or the steps on the main story. In the end the maven build had no errors, in yet there failures in the test.
Any thoughts?
OK. After some searching around I managed to find that this issue was fixed in JBehave 3.8.
JIRA link: http://jira.codehaus.org/browse/JBEHAVE-841
I updated to latest jbehave version and this works fine.