I have a build for an Ionic project and its E2E testing with SauceLabs. The build is timing out after 49 min 17 sec(50 min). All of my jobs are running well and logging output frequently at least every 1-2 min. The timeout is happening consistently at 50 min.
My build goes meets all the requirements as mentioned here to not suffer a time out. Also, there is no timeout for the build as mentioned in the docs. So the build shouldn't timeout as it is happening in the case. Any resolutions for this Issue?
Here are some of the logs:
https://travis-ci.org/magician03/moodlemobile2/builds/241500777
https://travis-ci.org/magician03/moodlemobile2/builds/241414546
https://travis-ci.org/magician03/moodlemobile2/builds/241401570
Your build ends with this message:
The job exceeded the maximum time limit for jobs, and has been
terminated.
It is the expected behaviour. Exists a limit of 50 minutes as explained here and here:
Build Timeouts #
It is very common for test suites or build scripts to hang. Travis CI
has specific time limits for each job, and will stop the build and add
an error message to the build log in the following situations:
A job produces no log output for 10 minutes
A job on travis-ci.org takes longer than 50 minutes
A job running on OS X infrastructure takes longer than 50 minutes - (applies to travis-ci.org or travis-ci.com)
A job on Linux infrastructure on travis-ci.com takes longer than 120 minutes
Some common reasons why builds might hang:
Waiting for keyboard input or another kind of human interaction
Concurrency issues (deadlocks, livelocks and so on) Installation of
native extensions that take very long time to compile There is no
timeout for a build; a build will run as long as all the jobs do as
long as each job does not timeout.
Your build doesn't complete before for a specific issue in your build.
I would ask another question focused in your code and language node_jsand no in this limit.
I develop native apps so I can not help on this topic but I found this ticket:
It seems that they updated Node.js to 6.X, tested it using Travis-ci, it failed and currently they don't use Travis-ci, so I would ask directly to MoodleHQ in their forums.
jleyva Juan Leyva added a comment - 03/Nov/16 6:05 PM Dani, can you
enable in your Travis account your moodlemobile2 repository so we can
see if Travis is working with the new dependencies? I already changed
the tracker fields so Travis is aware of the branch (but it requires
first you to enable you forked moodlemobile2 repo)
jleyva Juan Leyva added a comment - 03/Nov/16 7:31 PM Builds are
failing: https://travis-ci.org/dpalou/moodlemobile2/builds/172896611
Protractor or Jasmine or whatever is not working with this dependency
set
You can also check related issues and compare, this configuration works using:
node_modules/.bin/protractor e2e-tests/protractor.conf.js --directConnect
in protractor-conf.js change chromeOnly to directConnect
Related
I have been using a self-hosted github runner for a few months now. It was working well for all along until at one point it stopped connecting to github.
I tried to run the connectivity check using ./config.sh --check and I got the following message in the generated log file.
Http response body: {"message":"API rate limit exceeded for x.x.x.x. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)","documentation_url":"https://docs.github.com/rest/overview/resources-in-the-rest-api#rate-limiting"}
It seems the runner has exceeded the API rate limit. I am not sure know how that happened because it supposed to be 60 API requests per hour and the runner was basically idling for some days before this happened.
The documentation URL mentioned in the error message above does contain information on how to increase the rate limit but it does not mention anything about how to do that when using self-hosted runners. Can someone point me in the right direction?
Situation: VisualStudioCode (Browser library) runs a couple of .robot files (manually started)
Then it pauses because of an error...
At that point the process breaks and there is no final report.html
If you stop the run it doesn't generate an report.html that's not what you want. You actually want the results until that point. (or even better described: you still want the links output.xml, log.html and report.html)
you should be able to generate lag.htm and report.html using the rebot command. however you need output.xml for this. output.xml is created when you run the tests. when you break you will probobaly not have all the resources you need.
I would suggest to assign test timeout to the test that causes the pause. When the timeout is reached the test will be stoped automaticaly and you should have all reports. You can also set it globaly for all tests eg.:
*** Settings ***
Test Timeout 2 minutes
I'm troubleshooting an Selenium script that runs through the Task Scheduler on a Windows Server. It's running in PowerShell using version 3.0.1 of the Selenium module (found here:https://www.powershellgallery.com/packages/Selenium/3.0.1) with the Edge browser (the one with Chromium).
The "The HTTP request to the remote WebDriver server for URL [localhost] timed out after 60 seconds." error has been quite persistent and only appears when run through the Task Scheduler. The script runs fine when running manually through ISE.
Also to note, there's another script that is more or less the same as the one having the issue, albeit using a slightly different url (same site). This second script runs without issue through the task scheduler. They're performing the same sequence of actions which is why I'm not entirely sure why it would fail for one script but not the other.
I haven't found a suitable solution while looking at other posters facing the same issue. Any help is much appreciated!
I had the same issue. I tried all kinds of code changes but the only step that worked for me was to change the Security Options in Task Scheduler.
Task (right-click) > Properties > General > Switch from Run whether user is logged on or not to Run only when the user is logged on.
I guess this would be a temporary solution. I'll keep looking and update this if I find a better solution.
In our dev environment we have lots of repos, lots of builds and lots of buildservers, and most of the time things work just like they should - however, we are seeing an increase in builds that fail because of timeouts.
These timeouts are not happening because we are getting close to the limit, but because something "gets stuck/blocked" in the pipeline and it stays on that step until timeout kills the build.
To better debug why that happens, we need to be able to query what builds fails because of this timeout, so we for instance can see, if it is a particular build server or agent that has this problem.
We can not find anything in the API that would give us the timeout error, but we can see that the UI is able to deduct it somehow:
So far we have narrowed it down to query all builds with completed status (through this API), but we get no completion reason, and buildtimes are never exact the same as the timeout of the build defintion, so "guessing" it from the execution plan will also be a bit shaky.
How can we filter our builds down to only the builds that have timed out?
We can use the below API to get details for a build.
Note: do not add timelineId, we should list all info
GET https://dev.azure.com/{organization}/{project}/_apis/build/builds/{buildId}/timeline?api-version=6.1-preview.2
If the build is canceled because of the timeout setting, we can get the message: The job running on agent Hosted Agent ran longer than the maximum time of xxx minutes. For more information, see https://go.microsoft.com/fwlink/?linkid=2077134
By the way, we can use the API Builds - List to filter all failed build. if the build is canceled due to a timeout setting. the result is failed instead of cancel.
I am currently using Teamcity to deploy a web application to Azure Cloud Services. We typically deploy using powershell scripts to the Staging Slot and thereafter do a manual swap (Staging to Production) on the Azure Portal.
After the swap, we typically leave the Staging slot active with the old production deployment for a few days (in the event we need to revert/backout of the deployment) and thereafter delete it - this is a manual process.
I am looking to automate this process using Teamcity. My intended solution is to have a Teamcity build kick off x days after the deployment build has suceeded (The details of the build steps are irrelevant since I'd probably use powershell again to delete the staging slot)
This plan has pointed me to look into Teamcity build chains, snapshot dependencies etc.
What I have done so far is
correctly created the build chain by creating a snapshot dependency on the deployment build configuration and
created a Finish Build Trigger
At the moment, the current approach kickoffs the dependent build 'Delete Azure Staging Web' (B) immediately after the deployment build has succeeded. However, I would like this to be a delayed build after x days.
Looking at the above build chain, I would like the build B to run on 13-Aug-2016 at 7.31am (if x=3)
I have looked into the Schedule Trigger option as well, but am slightly lost as to how I can use it to achieve this. As far as I understand, using a cron expression will result in the build continuously running which is not what I want - I would like for the build B to only execute once.
Yes this can be done by making use of the REST api.
I've made a small sample which should convey the fundamental steps. This is a PowerShell script that will clear the triggers on another build configuration (determined by the parameter value in the script) and add a scheduled trigger with a start time X days on from the current time (determined by the parameter value in the script)
1) Add a PowerShell step to the main build, at the end and run add-scheduled-trigger as source code
2) Update the parameter values in the script
$BuildTypeId - This is the id of the configuration you want to add the trigger to
$NumberOfDays - This is the number of days ahead that you want to schedule the trigger for
There is admin / admin embedded in the script = Username / Password authentication for the REST api
One this is done you should see a scheduled trigger created / updated each time you build the first configuration
Hope this helps