I have an Ab-Initio plan consisting of more than one graphs in it. If the plan failed in one particular graph during its 6th phase, then how can the plan be restarted from the particular graph and that too from the beginning.
Note: Not for the last check point available in the .rec file.
In this case what should i do?
Delete the respective *.rec file from the run directory for the plan it was created. And rerun the graph. As it will not find any recovery file it will execute from the beginning.
One approach would be that you can disable the remaining graphs by selecting them, right click and then select disable. Now when you run your plan, only the enabled process will run without having to rerun the entire process, hope this helps and in case it does, pleas check the tick mark on the left and mark it as a correct answer and upvote.
Abinitio provde excellent first-line support services for their customers. I would recommend you email them support#abinitio.com. From experience it helps if you state your co>op version and your gde version and package the graph in question and send that as well.
Related
We use the SharedResourceScope Activity in our build process to make the deployment to the Symbol-Cache 'thread safe'.
Since friday auquiring the lock fails on every build
"TF270014: SharedResourceScopeActivity 'Synchronize Access to Symbol Store' timed out waiting for a lock on the resource '\netapp01-cifs01\tfs-droplocation\SymbolCache'."
and we don't have a clue why. Restarting all servers involved did not help, disabling anti-virus software, firewalls etc. neither. The network share is available as well and we checked all acces-rights, to be sure.
The MSDN does not document how the lock is established and decompiling the code did not provide a solution either because the search ended at the ISharedResourceExtensioninterface (BeginRequestSharedResourceLock) because it has no implementation in the Microsoft.TeamFoundation.Build.Workflow.dll which contains the Activity itself.
Can anyone help with this problem?
We could not find the implementation but as a hint for others having the same problem.
The TFS (using 2013 right now) holds its locks for shared resources in the database in a table called:
tbl_SharedResources
Clean up this table by nulling out the relevant columns and the lock is gone.
In TFS 2012 (any maybe other versions) the table is called: tbl_SharedResource.
Try to set the "MaxWaitTime" property of SharedResourceScope Activity "New TimeSpan(1,0,0)" to see whether it is helpful.
I created a task on jira (agile) by using kanban board but, I couldn't move it to "in progress" column. Finally I found the solution. You can see the problem and the solution step by step via pictures.
The problem is this:
Follow the topic to find the solution.
Just follow the steps. if you know a better solution, please share it.
The solution is:
Go to administration panel, open integrity checker, select all and click to Check.
Select Fix all and click Fix.
You'll see the fixed issues. Then click OK.
Finally you can do anything with your task again.
Now follow the pictures.
step 1
step 2
step 3
step 4
Please note that the usual reason for this problem is that the Conditions in the workflow are incorrect and the user does not match the rules set by them.
The problem answered by the main answer here only applies when you have corrupted data.
It also neglects the fact that you should treat corrupted data as a potential problem that you should investigate - it will be caused by crashes, or broken add-ons or scripts and you should track them down and fix them.
I'm attempting to modify my build process file for TFS 2010. I have a flag that is set when queuing the build, and when said flag is set, I want to create a Label, and add all the source files in the compiled project to that label.
On sequential builds, with the flag set, I than want to replace older source files in said label with anything new in the changeset being compiled.
I've been attempting to do this with LabelSources with no luck, and there is but vary poor documentation on either LabelSources or LabelWorkspace (whats the difference?).
Here's what I currently have:
<mtbwa:LabelSources
Child="[LabelChildOption.Replace]"
Comment="Published to Container"
DisplayName="Create Container Label"
sap2010:WorkflowViewState.IdRef="LabelSources_1"
Items="[{"$/Foo/LabelTest/Sandbox/"}]"
Name="[String.Format("{0}-{1}", LabelName, Version_Container)]"
Recursion="[RecursionType.Full]"
Scope="$/Foo"
mva:VisualBasic.Settings="Assembly references and imported namespaces serialized as XML namespaces"
Version="T" />
It definitely hits the action, but no labels can be found after the fact.
Any help would be much appreciated. and Any tangible documentation, other than Class Documentation with sparse definitions would also be greatly appreciated
Edit 1: Tried to clear up my goal.
What you are trying to do is built into the existing template. There should be an option in the process definition that refers to Clean Sources which will be set to True.
This option controls wither the build sources get cleaned, deleted and start afresh. Or if a differential is done.
If you have a lot of source code you can set clean sources to false and save a bunch of time getting the code.
You can also speed the build by placing a TFS Proxy on the build box which will cache the files and make a clean build quicker.
In my experience, Most of the built-in activities are poorly-documented for a reason - their only well-tested use case is their use inside TFS' built-in templates (DefaultTemplate.11.0.xaml, etc.). I'm afraid you're going to have to write some custom code, in the form of a custom activity, powershell script or something, to achieve other goals.
That said, I don't really understand the process you're trying to set up. Do you just want to have a label set as your latest-successfully-built sources? Why not use the one created automatically by the build itself?
I'm using the Build Explorer to delete our project's builds. It's taking forever because it's 'timing out' trying to delete the label and drop location (now that the drop location doesn't exist any more).
So, I'm hoping to do this via the command line to see if I get more love.
Is this possible?
Yes it is, see the following HowTo on MSDN.
How to: Delete a Completed Build (Command-Line)
However, I'm not sure that this is going to improve the situation for you as it basically does the same server calls that the UI does. Give it a try anyway. In the meantime I'll go ask a few folks and I'll edit this answer if we come up with anything to help you with your timeout issues.
The TFS Build Manager utility will let you multi-select and delete. It still works serially but at least it's only one manual step.
I've seen the post about disabling work item creation on all failed builds, but I'd like to have TFS only create a work item on the first failure. We have a very complicated legacy system that involves VB6 COM components and frequently have build failures on the build server that track back to some funkiness VB6 does with binary files (frx, ctl, etc. -- if you haven't had to deal with that in a while, you don't want to). The only way to resolve those issues is to try to make updates on a developer machine, then check in the files and run the build again (since the build doesn't fail on the dev machine). So we may have three or four (or more) failed builds before we get a success, which means we'll have three or four work items to close out.
Ideally, I'd like to have the following:
Joe checks in a change that causes the build to fail
A work item gets created and assigned to Joe
Joe checks in another change and the build still fails
No additional work item creation
Joe checks in a change the build succeeds
The work item assigned to Joe in step 2 above gets marked as Closed
But I'd be happy with just steps 1 through 4.
How would you determine that the second failed build was related to the first one, since there's an additional check-in involved? What happens if the next check-in is actually additional code committed by another developer - you'd want them to know their code broke the build, or that it's still broken, even though according to your steps, nothing would be triggered.
You'd either need to find a way to link the builds - for example, track who the auto-work-item is assigned to and then not create another work-item for checkins from that developer until there's a successful build, and maybe you could somehow queue up the builds for the other developers. I'm not really sure how you'd do it.
Does this move you in the right direction?