We use Visual Studio LabManagement infrustructure and TFS API to run our automation test from builds. Some of our test require reboot of system before they can be launched.
We noticed strange behaviour. When QtAgent is stoped by system (and not with a button Stop, pressed by human being), Test Controller is not notified automatically and environment remains in Ready state (status).
It goes to error when we invoke WaitForEnvironmentReady activity to determine that test machine is really ready to execute test (or other word connection between QtAgent service and Test Controller has been already established).
Is there a way to force Test Controller to get actual information about state of Environment without waiting for timeout is expired.
The controller will come to know about the agent going down after a timeout period specified in the testcontroller configuration xml. Once the controller detects this the environment state should move to notready on next refresh.
You can change these defaults as needed
See - http://msdn.microsoft.com/en-us/library/ff934570.aspx
Related
I would like to start a long running task from an API controller and return 200 when the task is started.
I want only one task running and if another request are coming in, the controller should check if there is already a task running.
It the task is running just forget the request. If not start a new task.
Was thinking of using this code fire and forget in ASP.NET Core with dependency alive to start the task. Then I need some thread safe place to store a IsRunning variable.
Have you checked Hangfire
?
In can be run in cluster mode and also you can query to check if a specific task in running.
We are "successfully" running our gherkin-testcafe build on ec2 headless against chromium. The final issue we are dealing with is that at a certain point in the test a CTA button is showing ...loading instead of Add to Bag, presumably because a service call that gets the status of the product, out of stock, in stock, no longer carry, etc. is failing. The tests work locally of course and we have the luxury of debugging locally opening chrome's dev env and inspecting the network calls etc. But all we can do on the ec2 is take a video and see where it fails. Is there a way to view the logs of all the calls being made by testcafe's proxy browser so we can confirm which one is failing and why? We are using. const rlogger = RequestLogger(/.*/, {
logRequestHeaders: true,
logResponseHeaders: true
});
to log our headers but not getting very explicit reasons why calls are not working.
TestCafe uses the debug module to perform internal logging functionality. So, in order to view the TestCafe proxy logs, you can set the DEBUG environment variable in the following manner:
export DEBUG='hammerhead:*'
I need to access the internet periodically (every 5 minutes or so) to update a database with a background service. I have tried the following using Android 8 or 9:
Use a boot receiver to start a JobService.
In onStartJob of the class that extends JobService, create a LocationListener and request a single location update.
Have onStartJob schedule the job again to run in 5-10 minutes.
Return true from onStartJob.
In the OnLocationChanged of the LocationListener, write to a local file, and start a thread to make a PHP request to update the database.
Everything works fine while the underlying process is running. When the process dies, the service keeps periodically updating the local file, but the the URLConnection.getResponseCode() now throws an exception - java.net.ConnectionException: failed to connect to ...
Is there a way to get around this using the above approach? If not, how can I have a background service access the internet even after the underlying process dies?
So I have my centralized logging system setup. But the thing I am currently working on is the self healing in my system. So suppose some error comes up through logs that this service is down. So I need a mechanism/open source tool using which I can write a script that when this type of error comes up, run this script and voila the service restarted/started working fine.
Thanks
Is there a way to know the return code or process ID of the process which gets executed when the privileged helper tool is installed as a launchdaemon and launched via SMJobSubmit().
I have an application which to execute some tasks in privileged manner uses the SMJobSubmit API as mentioned here.
Now in order to know whether the tasks succeeded or not, I will have to do one of the following.
The best option is to get the return code of the executable that ran.
Another option would be if I could create a pipe between my application and the launchd.
If the above two are not possible, I will have to resort to some hack like writing a file in /tmp location and reading it from my app.
I guess SMJobSubmit internally submits the executable with a launchdaemon dictionary to the launchd which is then responsible for its execution. So is there a way I could query launchd to find out the return code for the executable run with the label "mylabel".
There is no way to do this directly.
SMJobSubmit is a simple wrapper around a complicated task. It also returns synchronously despite launching a task asynchronously. So, while it can give you an error if it fails to submit the job, if it successfully submits a job that fails to run, there is no way to find that out.
So, you will have to explicitly write some code to communicate from your helper to your app, to report that it's up and running.
If you've already built some communication mechanism (signals, files, Unix or TCP sockets, JSON-RPC over HTTP, whatever), just use that.
If you're designing something from scratch, XPC may be the best answer. You can't use XPC to launch your helper (since it's privileged), but you can manually create a connection by registering a Mach service and calling xpc_connection_create_mach_service.