I have a buildbot running with two Schedulers - One triggered by code checkins and another triggered by content checkins; the former needs a much shorter treeStableTimer. Both of these Schedulers trigger the same builder, but what happens now is that everyone gets build notification mails twice for each checkin; once for the code scheduler and once for the content scheduler.
For example, if the following checkins go in...
CL# 1000 12:00pm user_a (code)
CL# 1001 1:00pm user_b (content)
...we'd see a build fire off on CL#1000 and send build notification mail to user_a. Then, a build would fire off from CL#1001 and send build notification to user_a and user_b - user_a gets two notifications that his checkin succeeded, when he should only get one.
I'd like to set things up so that we have two Schedulers, but when a builder triggers and sends email, it sends notification to the number of people who checked in since that builder's last build, not that Scheduler's last build. This seems straightforward conceptually, but I haven't seen anything on this in the docs or forums.
What's the right way to do this? We do need different treeStableTimers on the same builder, and people need build mail notification when their build completes, regardless of which of the two Schedulers triggered the builder.
Are you using fileIsImportant to pick out which which changes to trigger on which scheduler? By default, this doesn't affect the list of changes passed to the source stamp (and build) as triggering the build. All it does is accumulate changes until a change to an important file is made. The onlyImportant paramaeter of schedulers can be used to discard unimportant changes, so they don't get included in source stamps (and thus don't trigger emails).
Related
I have an MVC web site, a storage queue and a WebJob. Users can request the generation of a set of reports by clicking a button on the web page. This inserts a message into the storage queue. In the past, the WebJob ran continuously and processed those requests fine. But the demand and size of the reports has grown to the point where the WebJob is slowing down the web app. I would like to still place the request message in the queue, but delay processing of all requests until the evening, when the web app is mostly idle. This would allow me to continue using the WebJob code and QueueTrigger functionality without having to waste resources by moving to a dedicated Worker Role, etc. The reports don't need to be generated immediately, so a delay is acceptable.
I don't see a built-in way to set a time window on processing. The only thing I have found is a powershell cmdlet for starting and stopping WebJobs (Start-AzureWebsiteJob / Stop-AzureWebsiteJob). So I was thinking that I could create a scheduled powershell job that runs at midnight, starts the webjob, lets it run, and then runs again early in the AM and stops it.
Does anyone know of a better option than this? Anything more "official" that perhaps I could not find?
One possible solution would be to hide the messages in the queue for a certain amount of time when they are inserted.
If you're using AddMessage method, you can specify this timespan value in initialVisibilityDelay parameter.
What this will do is ensure that the messages are not immediately visible in the queue to be picked by WebJob and will become visible only when this timespan elapses.
Will such a solution work for you?
Maybe I didn't fully understand your question, but couldn't you use "Triggered" WebJob that is triggered by CRON schedule? You can then limit it to specific hours
0 * 20-22 * * *
This example will run every minute from 8pm to 10pm
I have set up a couple of daily tasks that update a SQL table and then sends out an email with a CSV attached. 5 of the scheduled tasks only complete successfully if the first task runs successfully. How would I add an argument in Task Scheduler to run the sequential tasks only if the first task was completed successfully?
The reasoning behind the request is due to the issue that sometimes the first script runs in a few minutes and other days it can take over an hour to complete. Any suggestions?
Thank you
It can be done! See here
http://blogs.msdn.com/b/davethompson/archive/2011/10/25/running-a-scheduled-task-after-another.aspx
In summary though say you have a task called Ping and you want a task called pong to run after it.
Create a task called Pong
Create an On an Event Trigger
Select Custom and edit the XML to be something like this
<QueryList>
<Query Id="0" Path="Microsoft-Windows-TaskScheduler/Operational">
<Select Path="Microsoft-Windows-TaskScheduler/Operational">*[EventData
[#Name='TaskSuccessEvent'][Data[#Name='TaskName']='\Ping']]</Select>
</Query>
</QueryList>
I dont think what you want is possible with the windows task scheduler. I would propose that you start the scripts that depend on the first one running successfully from the first script itself. That way you can be sure it has finished its work.
Also the title of your question is kind of misleading, something like "Creating dependencies in TaskScheduler" would fit better.
If your task that takes a varying amount of time leaves a Windows Event Log entry Event ID code specific to the successful completion of that task, you should be able to make your other tasks use the task scheduler trigger type "On an event" with the associated Log, Source, and Event ID.
If it doesn't, the other proposals are probably the only options left.
We have run into this same need several times. The 2 ways we have created the 'Dependency' type functionality is to:
Set the schedule to be run say every 30 minutes. In the startup of your app see if the dependency has been completed, if not exit, otherwise do you processing.
When there have been multiple dependencies we created an app that managed those. Each process that needed to be run depending on the others would be launched from the new Controller App (CA)'. The CA is scheduled to run every 30 minutes (or what every makes sense for your process) and it controls the multiple apps by checking of the dependencies and running the next app. We don't leave the CA running, we spawn the process to run and exit. Next time CA launches it checks dependencies and takes action needed or exits till launched again.
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.
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!
Is it possible to cancel a long running activity while still keep the whole workflow alive. The workflow itself is hosted in WorkflowApplication.
The real user case is we've got a long running activity which polls the price from an external web service, and once it gets the price the activity should complete and the workflow will move to its next step. However, the price is something nice to have but not mandatory, so in some cases we want to cancel the polling activity and let the WF carry on its execution.
So the question is how can I notify a running workflow to cancel (actually skip) its current activity.. if this is not possible at all, can someone please share your thoughts and point me the right direction to achieve this goal.
Thanks a lot.
Dan
You can do this using a Pick activity. Use one PickBranch trigger to poll for the price and add a skip polling bookmarked activity to the other branch. Whatever branch completes first continue and the other will be canceled.