This is a very specific question about one of our cloud-builds.
A certain build, that is usually running within 10 minutes, is running almost 2 hours now. It seems that it is stuck in one build step. I tried cancel the build through the website and the cli via gcloud builds cancel but both didnt' work.
Although gcloud is returning Cancelled [https://cloudbuild.googleapis.com/v1/projects/.../builds/...], the build still is up and running.
Our build-timeout is set for 30 minutes but it was simply ignored.
Any idea how to cancel this build?
Ok, problem "solved" itself after waiting long enough. After almost 2 1/2 hours the build finally canceld itself.
The same build triggered afterwards finished without any problems.
Related
I frequently get errors like
warning: failed to remove Build/x86-vxworks-kernel-gcc-Release-Ninja: Permission denied
in my CI build. Investigating the build server, I see it is always cc1plus.exe stuck in this folder. From the comand line of cc1plus.exe I can see, its a (random) cpp file being translated. I guess the real compiler I call in CMake (c++pentium.exe) redirects to this executable.
I am pretty sure (although I cannot prove it) this occurs on servers when builds are canceled. The error message does not come from cancelled build, it comes from custom pre-build clean steps of the following builds.
I do net recall getting this locally. Maybe it is related to how the CI is stopping the Build?
Setup:
Azure DevOps Server (on premise)
CMake + Ninja
VxWorks 6.8 GCC compiler (4.1.2) (I think its based on mingw)
Have you seen similar issues? Any general tips where I could further investigate?
Can i configure the build (yaml) to not cancel steps but wait till they finish or timeout? I guess this would also fix it with fairly low overhead in build time.
Can i configure the build (yaml) to not cancel steps but wait till they finish or timeout? I guess this would also fix it with fairly low overhead in build time.
As workaround, we could set the Even if a previous task has failed, even if the build was canceled on the Control Options for ninja task/step:
Check the document Specify conditions for some details.
Note: Don't forget to set Timeout.
Hope this helps.
I have created scheduled tasks to run each day at various times in the morning, on 6 different machines, all running Windows 7 x64.
These tasks have largely worked over the last few years, but we have a persisting issue with tasks not triggering at times, and never after a restart.
Without touching the Task Scheduler application at all, restarting the machine will mean that the next time the task is meant to be triggered, it doesn't work.
Running any task manually after the restart appears to avoid the issue.
This issue exists for scheduled batch files and PowerShell scripts.
Is there a specific setting that is needed to keep the task working after a system restart, or is this a known outstanding issue?
The most recent time this happened, we have captured the history:
Error | 27/02/2017 03:15:00 | 101 | Task Start Failed
Information | 27/02/2017 03:15:00 | 107 | Task triggered on Scheduler
Result code for failure: 2147943645
Update 2017-03-01: One machine doesn't work and produces the above error, and another machine shows nothing at all. Clutching at straws about this issue here.
If I tick the box 'Run whether user is logged on or off' The task is invisible. We can't do this. Any other suggestions are welcome!
Update 2017-03-02: Ticking 'Run whether user is logged on or off' is causing no end of issues. None of our Access macros run anymore, and other 3rd party applications called from the batch don't work with numerous permission errors. This is not the solution!
This can occur if the task trigger was set to run One Time when created. It is possible to set a task to "Run as soon as possible after a scheduled start is missed". This will cause the task to re-run after a reboot if the trigger was missed. However, this does not occur if the task is set to run One Time. This behaviour is by design.
You can work around this issue by setting a time and date under the Expire option of the task. This option can be reached by opening the Properties of the task, selecting the Triggers tab, and then clicking the Edit button for the trigger in question. If a date and time are set for the Expire option, the task will attempt to refire on reboot if its previous trigger time was missed.
I suggest you to set the trigger to "At startup". After you rebooted the machine, the task should then be in the "Queued" status. This means it will run at the configured interval.
This issue got resolved by updating 2 options in tasks.
Set task to “Run as soon as possible after a scheduled start is missed” in the settings tab.
Set expiry for task in trigger tab
But if you have multiple jobs like us. updating every job manually is an tedious work.
This PowerShell script I wrote will help you with that.
For me I had to change «for a duration of..» to «Indefinitely» and had to change the «Daily» to «One time»
I have some tests configured to run every morning at 05:00 UTC-4.
The triggers seems to be spotty however. It has ran a number of times, including on May 4th and May 5th, but it has failed to run this morning as well as on a few other days since I've configured the trigger.
Anyone know what might be causing this? Is there any way to retrace why the triggers failed to run?
I figured out the issue.
In the trigger properties, there is a checkbox that is check marked by default when the trigger is created:
Trigger only if there are pending changes
I unchecked it, and I expect it will work as expected from here on. I want my tests to run daily, regardless of whether there was changes to the testcases or not.
I've been working on using Xcode server to build my app, and have been running into some snags. The most recent involves Bots running over-zealously. I'll commit and push one change to one file, and two builds get triggered, separated by a minute or two. This also happens if I click the "Integrate Now" button, or if I make changes to the bot, with "Integrate immediately" unchecked.
Since my build takes a while to run, this is a pretty big problem, especially when I'm trying to iterate on Bot configuration.
Is anyone aware of what process triggers builds, or how can I troubleshoot this type of failure in general? It seems like there are multiple daemons listening for the signal to trigger the build or something like that.
Since it may be a bug in the Xcode beta, I submitted a radar (rdar://20456212)
I had the same problem. I changed the bot so that it does not do a clean for each integration and now it only does one build per commit. My guess is that the clean process and download of code was taking so long that the bot was being triggered before it was complete. So now I clean once a day and I only get a double build on the first build of the day. Hope this helps.
I'm looking at my build messages and it seems to get stuck here for a long time. This has only happened recently and very suddenly. I've tried to revert to previous revisions to no avail.
Libtool /Users/vu1/Library/Developer/Xcode/DerivedData/ThatInbox-astseeahhgcuwhgerbsnyfttztht/Build/Products/Debug-iphonesimulator/libPods.a normal i386
It gets stuck at the above line for about 8-10 minutes sometimes with a clean build. 5 minutes or so with a previously successful build.
I've tried cleaning, deleting the derived data, trimming all cocoapods libraries with no success. I've also tried deleting the xcode project in the package folder and allowing it to reindex. It takes about 5-10 minutes to build even coming off of a successful build. In the past, it may have only taken 10-15 seconds at most.
Any ideas on where I should begin looking?