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.
Related
Visual Studio Version 15.2 (26430.6) Release.
Having recently updated to the above version I am running into continuous issues with VS locking up files when trying to build.
Could not copy "obj\Debug\projHype.dll" to "bin\Debug\projHype.dll". Exceeded retry count of 10. Failed.
Also tried running VS2017 with and with out admin priveledges
I tried the suggestions for older versions of visual studio but to no avail. Any ideas how to get around this?
For anyone encountering this. Updating to version 26430.12 will resolve this. Looks like the previous release contained a bug.
While there may be other causes, testhost.exe and testhost.x86.exe can both result in a lock that prevents the build from completing. The symptoms are bewildering-- the test explorer churns indefinitely, sometimes timeout warnings appear in the build. Sometimes the files cannot be accessed even after VS is shut down.
If you are using nUnit or another test framework, make sure that test discovery does not encounter any infinite loops or crashes in your code. If this happens, it can hang the testhost executable. For example, if you use nUnit TestCase or TestCaseSource, if any of these perform an action that can hang, lock up, or crash, they will be invoked before the tests are executed.
This is the tricky bit-- your tests haven't run yet, but your code can lock up VS! While this may not be your problem, if you have unit test discovery in any way, check that it all completes.
One way to make sure all discovery completes is to use the functions from a test itself, and disable them as a TestCase or TestCaseSource (or equivalent in other test frameworks). If the test hangs or crashes, that's the culprit.
For me it helped to run the program again with accepting "run last successful build". After the run, the locks were gone.
When I queue my builds in VS 2013 using the "Hosted Build Controller"(Visual studio online) my build keeps saying:
![enter image description here][1]
Position In Queue = 1 (Waits in the Queue for more than half an hour)
It is not starting my builds inspite that fact that I have no other builds in queue or or running.
Sometimes it gives me the message saying the connection to the build server was lost.
Not Sure why this is happening because earlier when I initiated my builds using VS 2010, my builds used to start immediately.
Any help is greatly appreciated.
You're dealing with what can be a painful issue. Have you tried creating another agent? You can specify which agent to use when queuing the build. If other agents work and not this once, you may have encountered a bug that requires updates to your current version of TFS.
If new agents consistently fail or don't fail always, then you're dealing with a bigger issue that can be due to performance, cross-geography issues, or with too much latency loading your template. I believe one thing that can cause issues with this is having too many agents. I would also try clearing your build caches out. C:\users[user]\appdata\local\temp (i.e. BuildAgent/Controller). Also, definitely make sure your build software matches your TFS version (including the update). Slight differences there can cause issues.
I'm not sure if this is specific to 2010. But, when I do a clean, I get several errors saying "Cannot unregister assembly XXX.dll. Could not load file or assembly XXX or one of its dependencies. The system cannot find the file specified." However, if I clean again, it works. Any ideas?
I ran into and posted about this recently and found that, from the sounds of things, this is an issue with MSBuild itself and the way it resolves dependencies. My situation is slightly different from yours, though: When I run Clean through the VS IDE, it goes off without a hitch, but when I run the Clean MSBuild task, I run into the error you opened this thread with.
In my case (I'm attempting to automate our build with MSBuild), the quick and dirty fix was to use the Exec task instead of the MSBuild task to clean (and build) the solution. For the Exec task's Command parameter, I use devenv instead of devenv.exe--although this still requires an installation of VS on the build machine, unfortunately.
I suppose another option (requiring more time than I have now) might be either to write a custom task that correctly determines dependencies and runs "Clean" against each in proper order, or write one which catches the "Could not load file...' exception and loops through the clean task until it the exception no longer pops up. (This latter seems more brute-force in approach, but might be quicker.) I'm kind of new to this, so both ideas might just be worth no more than a quick flushing.
In either case, if since starting this thread you've come up with a solution, I'd love to hear about it. Good luck.
I'm trying to create a C++ CI environment by using CDash.
I've got CDash running on my computer and I can send some results to it from the CDash clients, by running the ctest manually.
I'm a bit lost on how to setup a client to automatically compile and test the code when the source code changes in the version control system (subversion), or at specific times.
I have the Mastering CMake book, but it doesn't seem to say much on that topic.
Is there any way to do the continuous build without hacking around with scheduled tasks / cron?
Is there any good example that would be useful to check out?
Can I somehow order to run a build on some site from the Dashboard? I kinda remember seeing this somewhere but I'm unable to find it now.
Is CDash any good for CI environments? (use comments to answer this one)
CDas#Home might be the solution. Generally I have my continuous machines run a script on a nightly cron job that polls the repository every couple of minutes for ~24 hours.
I'm interested in knowing which parts of my rake-based build (running within TeamCity) is slow. Is there an MVC-filter-style way I can wrap rake-tasks so that each one runs within a timer, and I output a breakdown of
time-spent on task including prerequisites (I guess the time between invoke starting and execute finishing)
time-spent on task excluding prerequisites (I guess the time between execute starting and finishing)
so that I can analyse which parts of my build are taking the most time, to target my optimisation efforts?
Does TeamCity have any features baked in that would do this for me? (I know I'll be able to chart the results of my performance-logging with custom-charts; I just wondered whether it could do this out of the box already.)
First, in TeamCity 6.0 there is a tree view of the build log. In this tree view you can see duration times spent for different blocks of your build.
Also, in TeamCity's rake runner, there is "Track invoke/execute stages" option, which can be enabled to get more information in your build log (and there is timing information for each record).
You can also try adding rake parameters like -t or -v in TeamCity rake settings to get more verbose output.
TeamCity also allows you to use custom service messages to provide more information to your log and to your build.
Hope this helps,
KIR