I am using the Invoke REST API task in as a pre-deployment gate in my environment. The task has been configured to wait for a callback from my service (external to VSTS).
The problem is that when I try to call into VSTS to mark the task as completed I always get an error saying orchestration session xxxxxx_xxxxxx_xxxxxx not found for hub Gates. The same code when used with release or build definitions work fine but fails with this error when used with gates.
Here is a snippet of my code that makes the API call
var taskCompletedEvent = new TaskCompletedEvent(jobId, taskInstanceGuid, TaskResult.Succeeded);
taskClient.RaisePlanEventAsync(projectGuid, HUBNAME, planGuid, taskCompletedEvent).SyncResult();
This problem occurs because of a slight deviation on how gates are executed when compared to builds or releases. In general, the safest way to update such server side tasks using the callback mode would be by using the TaskClient maintained by the VSTS team itself, which takes care of all such quirks.
The slight change that can be made in the original code to make it work would be -
var taskCompletedEvent = new TaskCompletedEvent(taskInstanceId, Guid.Empty, TaskResult.Succeeded);
taskClient.RaisePlanEventAsync(projectGuid, HUBNAME, planGuid, taskCompletedEvent).SyncResult();
The difference lies in how the event is initialised. The TaskId parameter is not defined and JobId is not used anywhere. The recommendation is still to use the TaskClient on GitHub to ensure everything continues to work fine even when the VSTS Release Management team decides to fix this rather annoying difference.
Related
I use Alfresco Community 5.2 and my need is to perform some work when one of the default Alfresco's workflow is started.
I could override all the workflows definitions, but I wonder if there is a better and quicker way to do that. The perfect would be a behavior which triggers when a workflow is started.
Is there something like that ?
Any other approach is accepted. Thanks.
There isn't anything similar to a behavior for workflows that I know of, although if your workflows will always have documents attached you could consider binding a behavior to the workflow package type (I don't recall off-hand what that type is--it might just be cm:folder which wouldn't be that useful).
This is kind of a hack suggestion, but you could implement a quartz job that would run every 30 seconds or every minute or so that would use the workflow service to check to see if any new workflows have started since the last check. If so, your code could be notified and passed the workflow ID, process ID, etc.
The straightforward solution is as you suggested in your original post--just modify the out-of-the-box processes with a task listener that fires when the workflow starts.
Following Jeff suggestion, and this tutorial, I managed to implement a task creation/completion listener and do my logic inside those blocks, resolving the problem.
we are triggering the runscope test using triggerid of the specific test. How can we learn the status of the test so we can progress our builds ?
We have a blog post that describes how to do this with Codeship, but the same methods (especially the polling done in the Python sample script) should be applicable to any CI environment.
Apologies for bumping an old post, but I was looking for something similar, that is, checking the Runscope results to automatically approve the next step in a release (as opposed to a build that OP asked about).
It seems that VSTS has the concept of Gates that can do some action and only progress the release when the action succeeds, with configurable timeout and retry. One of the actions is Invoke REST API, which would probably do the job.
https://learn.microsoft.com/en-us/vsts/pipelines/release/approvals/gates?view=vsts
Note, I haven't actually tried this yet, so YMMV
I have a WCF Windows Workflow (4.5) Workflow Service hosted under IIS and using AppFabric 1.1. The workflow instances are long-running (up to about a week), but much of the time is spent in Delay activities.
This seemed to work fine at first, but when running multiple instances of the workflow at the same time (2+ instances causes this), some of them just never wake up once they've unloaded from memory during the Delay step. When I look at the logs, the errors I find all look like this:
System.OperationCanceledException: The execution of InstancePersistenceCommands has been canceled because the InstanceHandle was freed.
at System.Runtime.AsyncResult.End[TAsyncResult](IAsyncResult result)
at System.ServiceModel.Activities.Dispatcher.DurableInstanceManager.WaitAndHandleStoreEventsCallback(IAsyncResult result)
Unfortunately, I'm not finding any useful information on that error message.
The SuspensionExceptionName and SuspensionReason fields in the AppFabric Persisted Instances Table show System.NullReferenceException: Object reference not set to an instance of an object. But this doesn't happen inside my workflow, only outside.
Additional Info:
I'm running the activity as a Fire & Forget (receive activity, no send)
My workflow calls into other WCF services to fetch data.
I am running this on Server 2012 R2, IIS 8 (not azure)
Workflow Persistence is working. I can reset IIS, reboot... its just when I run 2 instances that it has problems.
I'm definitely not hitting any kind of throttling limits. While the workflow deals with a few MB of data, this issue happens at 2+ instances.
Any idea what might be happening here?
Edit:
I realized I found more information on how the issue operates and never added it to the question. When the delay issue happens, it operates a lot like a static variable getting written by 2 threads.
Here's a visualization:
WF1 Start ---->Do Stuff--->Sleep------------*1----->Cancelled Exception at some point
------WF 2 Start---->Do Stuff------->Sleep->Wake up---------*2------>More Stuff---->End Successfully
*1 - When WF Instance 1 Should Wake up (Same time as WF 2 wakes)
*2 - When WF Instance 2 Should have woken up (Seems to be ignored)
Before anyone asks... I got rid of every static variable, method, class in my code. Nothing is static anymore.
I've been struggling with similar issues for quite a while. I use WFW4 and I find similar errors when a workflow instance is in a long delay.
I don't know what the cause of the problem is, but I have a work around that you might find helpful.
In my case, the errors I get are from Workflow Management Service and say:
Failed to invoke service management endpoint at 'net.pipe://.svc' to activate service '/Alerts/Workflows/.xamlx'. Exception: 'Access is denied.'
These errors start happening sometime between 6 and 30 hours after the instance goes into a long delay.
I have found that if I create a new instance of the workflow when the first instance is in delay and the errors are happening, then Workflow Management Service is able to resume interacting with the first sleeping instance.
So, I made a new workflow whose sole purpose is to periodically launch and then kill instances of the workflow that contains the long delay.
It actually gets a bit more complicated to make this work. I wanted this new workflow to also go to sleep between times when it creates and kills a new instance of the first workflow. But this going to sleep causes the instance of the new workflow to suffer the same problem as the first workflow. So, I modified the new workflow so it does the following:
-- delay for some rather short period, such as 30 minutes
-- create an instance of the first workflow
-- wait a minute
-- kill the just-created instance of the first workflow
-- create a new instance of this new error-preventing workflow
-- terminate
Since having done this, I no longer get the Access is Denied error from Workflow Management Service!
Hope this helps
Turns out my first answer was not correct, but I believe this answer is right, and solves the issue ChrisG is having.
My workaround did not actually work. Took a while for the problem to resurface. 29 hours to be precise - the default time it takes for an app pool to recycle.
So for me, the solution was to make my app pool not recycle. When an app pool recycles while a workflow instance is in a delay activity, the workflowManagementService is not able to wake up the instance and throws Access is Denied errors. If you create a new instance of the workflow after the app pool has recycled, the first instance will pick up where it left off, but sometimes still has problems, which is what I believe is happening to ChrisG.
ChrisG, looking at your visualization, is it possible that an appPool is recycling during the time wf1 is sleeping? I believe that is the cause the exception. If you then launch a new wf instance after *2 has passed (and if an app pool recycle happened prior to *1), that will wake up both wf1 and wf2, but wf1 won't work properly (at least in my experience)
Also, this happens after iisresets and server reboots. To handle those, you need to use IIS7 which allows the web application (as well as the web site) which is hosting the xamlx files to autostart after an iisreset or server reboot. This option is not available in IIS6. See http://www.postseek.com/meta/991815402b369e71ce925cde47ac907d for details
Hope this helps!
I use the TeamCity (7.0) REST API to allow developers to trigger custom builds. I add the build to the queue like this:
http://teamcity/httpAuth/action.html?add2Queue=[buildTypeId]&name=[propName]&value=[propValue]
My question is how I best can track the progress of the build just triggered. The REST call does not return any info about build ID assigned to the build, so even if I poll the list of builds (running/finished) I will not know if one of them is the one I triggered. There could potentially be several builds for the same buildTypeId in the queue, so I need a way to separate out the one I am after.
I read somewhere a suggestion that you could add a build property with a unique value to each build you put in the queue, and then later poll the build list and look for one with that exact property value. I have however not found a way of listing the properties for the builds, so I am still stuck. This REST call does not provide information about properties:
http://teamcity/httpAuth/app/rest/builds/?locator=buildType:[buildTypeId]
Any suggestions on how to solve this? I would ideally like to know if the build is in the queue, if it is running, and when it's done I would like to get the status. The most important is however to know if it is done and what the status has.
After some further investigation I came up with a solution for this which seems to work fine:
I found out that even though you did not get any information about the custom build properties using the "/builds/?locator=buildType:x" call, you could extract the build ID for each one of the builds in that list and then do another REST call to get more details about one specific build. The rest call looks like this:
http://teamcity/httpAuth/app/rest/builds/id:{0}
The response from this call will give you a "build object" which contains a list of build properties, among other things.
My solution for tracking the build progress was then like this:
When a build is added to the TeamCity queue, I first add a property to the URL called "BuildIdentifier". The value is just a GUID. I pass this identifier back to the client application, and then the client starts polling the server, asking for the status of the build with this specific identifier. The server then goes through some steps to identify the current stage of the build:
1: Check if the build is running. I get the list of running builds with the call "/builds?locator=running:true", iterate through the builds and use the build ID to query the REST API for details. I then go through the details for each running build looking for a build with a matching "BuildIdentifier" property to the one I received from the client. If there is a match in one of the running builds I send a response with a message that the build is running at x percent (PercentageComplete property of the build object) to the client who is tracking the progress. If a match is not found I move on to step 2.
2: Check if it is finished: First get the latest build list using the "/builds/?locator=buildType:x" call. Then do the same thing as in step 1, and extract the X latest builds from the list (I chose 5). In order to limit the number of REST calls I set an assumption that the build would be in the latest 5 builds if it was finished. I then look for a match on the BuildIdentifier, and if I get one I return the status of the build (FAILED, SUCCESS, etc.).
3: If there was no match for the BuildIdentifier in step 1 or 2 I can assume that the build is in the queue, so I return that as the current status.
On the client side I poll the server for the status every x seconds as long as the status is saying that the build is either in the queue, or running.
Hope this solution could be helpful if there are someone else with the same problem out there! I would think that tracking the progress of a triggered build is a pretty common task if you use the TeamCity REST API.
The Queued Builds rest api is the best way to accomplish this but has only been available since version 8.1.
To start the build send a POST request to ~/httpAuth/app/rest/buildQueue like this
{
buildType: { id: "bt667" },
branchName: "master",
properties: {
property: [
{ "name": "Property", "value": "test" }
]
}
}
The response contains a href which can be used to check the status of the build.
{
...
"href": "/httpAuth/app/rest/buildQueue/taskId:49337",
...
}
To check the status of the build queued send a GET request to the href specified in the response from step 1.
This is a huge improvement over the previous API.
Since TeamCity 8.1, REST API got a dedicated way to trigger a build and tracking the queued build results is much easier as the build queue request returns the link to the queued build which can later be used to track the build's current status.
See details in the TeamCity documentation.
I have a web application that I am adding workflow functionality to using Windows Workflow Foundation. I have based my solution around K. Scott Allen's Orders Workflow example on OdeToCode. At the start I didn't realise the significance of the caveat "if you use Delay activities with and configure active timers for the manual scheduling service, these events will happen on a background thread that is not associated with an HTTP request". I now need to use Delay activities and it doesn't work as is with his solution architecture. Has anyone come across this and found a good solution to this? The example is linked to from a lot of places but I haven't seen anyone else come across this issue and it seems like a bit of a show stopper to me.
Edit: The problem is that the results from the workflow are returned to the the web application via HttpContext. I am using the ManualWorkflowSchedulerService with the useActiveTimers and this works fine for most situations because workflow events are fired from the web app and HttpContext still exists when the workflow results are returned and the web app can continue processing. When a delay activity is used processing happens on a background thread and when it tries to return results to the web app, there is no valid HttpContext (because there has been no Http Request), so further processing fails. That is, the webapp is trying to process the workflow results but there has been no http request.
I think I need to do all post Delay activity processing within the workflow rather than handing off to the web app.
Cheers.
You didn't describe the problem you are having. But maybe this is of some help.
You can use the ManualWorkflowSchedulerService with the useActiveTimers and the workflow will continue on another thread. Normally this is fine because your HTTP request has already finished and it doesn't really matter.
If however you need full control the workflow runtime will let you get a handle on all loaded workflows using the GetLoadedWorkflows() function. This will return acollection of WorkflowInstance objects. usign these you can can call the GetWorkflowNextTimerExpiration() to check which is expired. If one is you can manually resume it. In this case you want to use the ManualWorkflowSchedulerService with the useActiveTimers=false so you can control the last thread as well. However in most cases using useActiveTimers=true works perfectly well.