I am using a powershell script that internally calls msbuild to build my solutions. This works in principle, so the solution files are ok.
I can repeat the build, it works flawlessly.
But the build hangs
the first time I start the script (after reboot)
after some time / actions during the work day, no idea what changes
So my suspicion is, that msbuild is using some component that is not loaded when I reboot / that is unloaded during the work.
But I have no clue how to find the problem...
I am using this exe:
C:\Program Files (x86)\MSBuild\14.0\bin\MsBuild.exe
Any ideas?
For anybody running into this issue: Roslyn does a "shared compilation" by default, which means that results of compiles are used for further compilations to gain speed. You can switch this of by providing "False" for UseSharedCompilation in VBPROJ files or using a similar switch for MsBuild. Switching this off will do slower compiles but the run does not hang.
Related
The VSTS msbuild task seems to keep executing CoreCompile, despite the Clean option being disabled and the source files untouched (nothing changed in the source fetch).
Yet locally when I run msbuild locally or directly on the build machine, it behaves as expected - all unmodified projects are not rebuilt; CoreCompile does not run csc.exe.
I found that this was because the "TargetFrameworkMoniker" file that MSBuild generates and injects into the compile silently is written to the temporary directory, i.e. what you get when you run System.IO.Path.GetTempPath().
The VSTS agents however, specify their own temporary directory (_temp) and seem to clear it after every build. This seems like good behaviour - it's MSBuild that should fix it (IMO).
A quick and dirty fix, that may not work if your projects use mixed frameworks, is to add this MSBuild option:
/p:TargetFrameworkMonikerAssemblyAttributesPath=$(Build.Repository.LocalPath)\temp.moniker.cs
Alternatively, you can disable the file generation with:
/p:GenerateTargetFrameworkAttribute=False
The Problem
I'm adding a pre-build script to our TFS build that calls npm install among other things. One package, gulp-imagemin, installs a few dependencies that each run a test when they install that says they've installed successfully. TFS is interpreting this output as an error even though it's actually a success message. It causes my build to "partially succeed".
The unrecognizable characters above are supposed to be a checkmark (I can see it when running locally)...apparently TFS is not a fan, but there are other lines in the output where this happens and it doesn't show an error next to it, so I don't think that's the cause.
Here's where that message comes from:
https://github.com/imagemin/gifsicle-bin/blob/master/lib/install.js#L34
Does anyone know why TFS is interpreting this as an error, or how I can fix this? Thanks much!
What I've Tried
I've tried to silence its output (by redirecting stdout and stderr to $null) to no avail. When running my .ps1 script locally, I can successfully silence that message, but when the script runs in TFS it still gets printed out. I'm not sure what the difference is.
I also tried making my script a .cmd script instead of .ps1 and that had an interesting effect. The silencing I originally intended worked, but then it would effectively skip the step and the remaining pre-build steps. When I removed the output redirect to nul so I could debug, it brought me back to the same error above with no new info.
To do this in-editor you open the automation tab, connect to the session and choose which tests to run.
How do you do it from the command line?
(NB. not compiling UnrealEngine/Engine/Build/BatchFiles/* comprehensively covers both building the application and compiling it. Specifically, given that you have code that is 100% happy to compile, how do you kick the test suite off)
--
Here's some more info, from recent testing on 4.10:
Running tests from the editor:
UE4Editor Project.uproject -ExecCmds="Automation RunTests MyTest"
Notice the absence of the -Game flag; this launches the Editor and runs the tests successfully in the editor console.
Running the game engine and using the 'popup log window':
UE4Editor Project.uproject -Game -ExecCmds="Automation RunTests MyTest" -log
This runs the game in 'play' mode, pops up an editor window; however, the logs stop at:
LogAssetRegistry: FAssetRegistry took 0.0004 seconds to start up
...and the game never closes or executes the tests.
Running the game engine and logging to a file:
UE4Editor Project.uproject -Game -ExecCmds="Automation RunTests MyTest" -log=Log.txt
This runs the game in 'play' mode, and then stops and never exists.
It does not appear to run any tests or log to any files.
The folder Saved/Logs does not exist after quitting the running game.
Running in the editor, test types, etc...
see: https://answers.unrealengine.com/questions/358821/hot-reload-does-not-re-compile-automation-tests.html,
Hot reload is not supported for tests; so this isn't an option.
There's also been some suggestion in various places that the test type (eg. ATF_Game, ATF_Editor) has some affect on if runs are or can be run; perhaps this is an issue to, but I've tried all kind of combinations with no success.
--
I've tried all kinds of combinations of things trying to get this working, with no success so it's time for a bounty.
I'll accept an answer which reliably:
Executes a specific test from the command line
Logs the output from that test to a file
Right, no one has any idea here or on the issue tracker.
After some serious digging through the UE4 source code, here's the actual deal, which I leave here for the next suffering soul who can't figure this out:
To run tests from the command line, and log the output and exit after the test run use:
UE4Editor.exe path/to/project/TestProject.uproject
-ExecCmds="Automation RunTests SourceTests"
-unattended
-nopause
-testexit="Automation Test Queue Empty"
-log=output.txt
-game
On OSX use UE4Editor.app/Contents/MacOS/UE4Editor.
Notice that the logs will, regardless of what you supply, ultimately be placed in:
WindowsNoEditor/TestProject/Saved/Logs/output.txt
or
~/Library/Logs/TestProject/output.txt
Notice that for mac this is outside of your project directory, in, for example, /Users/doug/Library/Logs/TestProject. (Who thought that was a good idea?)
(see https://wiki.unrealengine.com/Locating_Project_Logs#Game_Logs)
You can list automation tests using:
-ExecCmds="Automation List"
...and then parse the response to find tests to run; automation commands may be chained, for example:
-ExecCmds="Automation List, Automation RunAll"
Do you mean the in-editor command line or the Windows command line?
In the editor you can use the Automation command with parameters, e.g. Automation RunAll
In the Windows command line you can specify unreal command parameters with -ExecCmds. To run all tests in your project: UE4Editor.exe YOURPROJECT -Game -ExecCmds="Automation RunAll"
For anyone still wondering, there is a bug in the editor that make it so the test list is flushed before they are run when they are started from the command-line (be it at startup or after).
This means that the editor actually compiles a list of tests to run, which is then flushed by another part of the program. The editor then thinks that it has finished running all the test and, since there is no errors, shows that they all succeeded.
I can post how to do a fix to this if anyone is interested, but it introduce another minor bug.
I have this rakefile that works fine when called from a "Start Command Prompt with Ruby" instance, but fails when called with rake.bat. This means I can't get it to work on Jenkins at all using the Rake build step plugin.
From what I can tell, it's the rake/clean task that's messing up and deleting all files in a "/Core" directory. I've explicitly excluded this from the CLEAN filelist, but when called from rake.bat, this is completely ignored.
What could possibly be the cause for this?
Edit:
OK, more info. CLEAN.exclude('**/core') is ignored the first time it's run in the Ruby shell too, but subsequent runs are fine. That explains why rake.bat is a problem 100% of the time.
I'm using rake 0.8.7, but the same thing happens with 0.9.2. Ruby version is 1.9.2p290. albacore version is 0.2.7. Windows 7 x64 (same thing happens on Windows Server 2008 R2 Standard)
OK, I solved it.
Should've realised it earlier, but it's mind-boggingly weird.
fails the first time: CLEAN.exclude("**/core", "**/bak", "**/~") # a comment here
this always works: CLEAN.exclude("**/core", "**/bak", "**/~")
I guess I'm henceforth removing all comments that are not on a single line in my rakefiles...
When trying to build the unit tests created using the default XCode Unit Test bundle target, it looks like it's stuck on the "Run custom shell script 'Run Script'" phase.
I also notice a high cpu usage on process "otest" to the point where the fans kick in within seconds.
The only useful message I see when expanding the line is
/Developer/Tools/RunPlatformUnitTests.include:419: note: Running tests for architecture 'i386' (GC OFF)
Couldn't open shared capabilities memory GSCapabilities (No such file or directory)
The only option I have at that time is to stop the build.
Have to say I was running unit tests perfectly fine up to this moment but can't say for sure what I did to cause that.
That's on XCode 3.2.4
After updating to 3.2.5 now the run script does fail with an error
Test rig '/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator4.2.sdk/Developer/usr/bin/otest' exited abnormally with code 138 (it may have crashed).
Guess they problem is related?
Did find some answers on SO about how exception handling now works differently when using NSInvocation (which otest seems to use) but not really a solution to this.
I had this happen to me. I made it go away by scrapping my old testing target profile, creating a new one, and pointing all my tests to it. I was too frustrated to compare the profiles line by line to figure out what had changed.
This looks like an infinite loop to me. Try adding some NSLog statements and/or debugging your tests with gdb (by adding otest as a custom executable).
This happened to me after updating to Xcode 9 and using script for updating localizable strings file, a minor bug caused the script to never finish. After updating BartyCrouch, everything worked normally.
https://github.com/Flinesoft/BartyCrouch/issues/66