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
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.
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.
While other story states are self-explanatory, I'm not quite sure what is the intended use of 2 distinct Finished and Delivered states.
I have watched the videos on the Pivotal website, but found them unhelpful - they just state that we can mark the story using those states, but does not explain how does it relate to the workflow.
So, why do we need them? What happens after the developer marks the story as Finished and before it gets Delivered?
I assume the following workflow:
A developer starts to work on the story, marking it as Started
Once the story tasks are completed and it passes the unit tests - it is marked as Finished
After ??? it is marked as Delivered
Then, after QA it can be Accepted or Rejected and restarted, if necessary.
Should we mark the story as Finished before some other kind of testing and then Delivered once it passes? Or maybe it should involve code review? Perhaps this is a common knowledge in agile/scrum world, that I am yet unaware of?
I do understand that this mostly depends on the conventions, established in the project, but I am looking for some best practices, since we are just starting to incorporate Pivotal Tracker into our workflow.
I just had this same question and watched those same videos you did, but also found a more detailed article on Tracker's workflow.
Based on their explanation, I have modified your steps as below. Obviously everyone is going to have slightly different takes on this, but I've tried to see things through the way your company might work based on your initial steps.
A developer starts to work on the story, marking it as Started
Once the story tasks are completed and it passes the unit tests - it is marked as Finished
Once the code is successfully deployed to the stage or test environment, it is marked as Delivered
Then, after QA it can be Accepted or Rejected and restarted, if necessary.
Hopefully this is helpful.
That's an old subject, but here's what we are doing in my company :
When a developer ends a ticket, he finishes the story.
Any finished story has to be reviewed by another dev
If the code review is okay, the code is merged to the testing branch
Then the requester delivers it
Firstly I am new WF (v4), but I can see the benefits, it's just the learning curve that is holding me back at the moment so I need your help.
Take my scenario, I have a business requirement to send a series of emails at various intervals. So I have created a sequential workflow in a workflow service with the appropriate delays between each mail send. The workflow is started by a Recieve call. This part seems to work fine.
However I want a have a second Receive call that effectively stops workflow so no more emails sent.
To try and achieve this I configured a Pick control with 2 branches. Branch 1 has a Receive with StartEmails which starts my delayed sequence of emails as describe before. Branch 2 contains a second Receive 'StopEmails, however my breakpoint never gets hit on the StopEmails Receive. I beleieve I have setup the correct correlation and CanCreatedInstance is set to false.
Is it that I can't make a second call while the first branch is in a delay (waiting) state?
Any pointers would be appreciated.
After a little more digging on SO, I believe I found my answer. see this post Workflow foundation 4.0 message correlation and error reporting
I was correct in my thinking that it was the delay in my first branch was what was blocking my second Receive request from being executed. Replacing my Pick with a Parallel container solved the problem. Makes sense when you think about it!
Parallel container to the rescue!
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.