Investigate Community Test Suite Issues

[DanielRosenwasser]

Failing Test Runs

As of February 11th, it seems like community test runs have been failing in strange ways

Test 3

##[error]Unhandled exception. System.IO.IOException: No space left on device
System.IO.IOException: No space left on device
   at System.IO.FileStream.WriteNative(ReadOnlySpan`1 source)
   at System.IO.FileStream.FlushWriteBuffer()
   at Microsoft.VisualStudio.Services.Agent.HostContext.Dispose(Boolean disposing)
   at Microsoft.VisualStudio.Services.Agent.HostContext.Dispose()
   at Microsoft.VisualStudio.Services.Agent.Worker.Program.Main(String[] args)
   at System.IO.FileStream.WriteNative(ReadOnlySpan`1 source)
   at System.IO.FileStream.FlushWriteBuffer()
   at System.IO.FileStream.Flush(Boolean flushToDisk)
   at System.IO.StreamWriter.Flush(Boolean flushStream, Boolean flushEncoder)
   at System.Diagnostics.TextWriterTraceListener.Flush()
   at Microsoft.VisualStudio.Services.Agent.HostTraceListener.WriteHeader(String source, TraceEventType eventType, Int32 id)
   at Microsoft.VisualStudio.Services.Agent.HostTraceListener.TraceEvent(TraceEventCache eventCache, String source, TraceEventType eventType, Int32 id, String message)
   at System.Diagnostics.TraceSource.TraceEvent(TraceEventType eventType, Int32 id, String message)
   at Microsoft.VisualStudio.Services.Agent.Worker.Worker.RunAsync(String pipeIn, String pipeOut)
   at Microsoft.VisualStudio.Services.Agent.Worker.Program.MainAsync(IHostContext context, String[] args)
System.IO.IOException: No space left on device
   at System.IO.FileStream.WriteNative(ReadOnlySpan`1 source)
   at System.IO.FileStream.FlushWriteBuffer()
   at System.IO.FileStream.Flush(Boolean flushToDisk)
   at System.IO.StreamWriter.Flush(Boolean flushStream, Boolean flushEncoder)
   at System.Diagnostics.TextWriterTraceListener.Flush()
   at Microsoft.VisualStudio.Services.Agent.HostTraceListener.WriteHeader(String source, TraceEventType eventType, Int32 id)
   at Microsoft.VisualStudio.Services.Agent.HostTraceListener.TraceEvent(TraceEventCache eventCache, String source, TraceEventType eventType, Int32 id, String message)
   at System.Diagnostics.TraceSource.TraceEvent(TraceEventType eventType, Int32 id, String message)
   at Microsoft.VisualStudio.Services.Agent.Tracing.Error(Exception exception)
   at Microsoft.VisualStudio.Services.Agent.Worker.Program.MainAsync(IHostContext context, String[] args)

Test 4
,##[error]We stopped hearing from agent Azure Pipelines 18. Verify the agent machine is running and has a healthy network connection. Anything that terminates an agent process, starves it for CPU, or blocks its network access can cause this error. For more information, see: https://go.microsoft.com/fwlink/?linkid=846610

Fluent UI?

It seems like in recent pull requests (last 30ish days?), we're not seeing Office UI Fabric getting mentioned in our community test suite runs: https://github.com/typescript-bot/TypeScript/pull/

Is the community test suite still testing Fluent UI (formerly Office UI Fabric)? There might be issues because the repo was moved to https://github.com/microsoft/fluentui, but it might be due to the above issue.

We should make sure we haven't lost coverage.

[weswigham]

So, an update here, the docker image we built to test office ui fabric is 9.44GB, the image we build ourselves in is 1.5GB. That puts the floor on space required at as 11GB. Azure devops hosted workers only guarantee "at least 10 GB of storage space" in the worker, hence you can see why we'd run into this issue eventually. After realizing that, my first thought was to port the task to actions - Github actions is a bit different - there's no stated limit, but heresay is that actions are run on a disk with ~29GB of free space by default, but may actually be limited to a similar ~14GB cap (it's running on the same underlying node, which only has a 14GB temp disk size). So even if migrating fixed the issue, it'd likely only so do temporarily, as the build/tests are likely to keep growing in size - so instead I started to look into purging the images between builds, but in doing so I had to make the build actually get to the built image stage again (they changed their build process a little bit and had broken our process) - in doing so, I made a change to how we inject ourselves, and, in doing so, on my local machine, halved the image size (which should buy way more than a little time). So... that alone should get it working, and does: #42961