0

I could observe that my Self-Hosted Agent (Agent.Version = 2.144.2) gain different results when a buildpipeline triggered manually or sheduled.

1. failed observation (Schedule nightly build at 3 am)

enter image description here

2. failed observation (Schedule nightly build at 3 am)

enter image description here

successful observation (Manual Build)

enter image description here

Sadly, I could also observer Schedule nightly builds with the same tasks that runs totally fine.

The Error

The sheduled builds failed cause the agent reached the maximum execution time of 1 hour. The reason is that the devenv.ps1 task need much longer that it usually does.

The Task: devenv.ps1 is a selfmade task and without knowing the details about this task, it is not possible to say what's going on here. It is a custom task based on a powershell script to perform a git clean, nuget restore, some individual prebuild events and finally a devenv rebuild.

In the logs I can't find a hint for this behavior.

The Question

Are there any reasons why a Manual task could have a different behavior as a Schedule task? Did anybody observe a similar behavior?

Edit #1

I switched from the custom devenv task to the offical Visual Studio-Build task. Unfortunately, the results do not change:

enter image description here

==============================================================================
Task         : Visual Studio-Build
Description  : Erstellen Sie den Build mit MSBuild, und legen Sie die Visual Studio-Versionseigenschaft fest.
Version      : 1.151.2
Author       : Microsoft Corporation
Help         : [Weitere Informationen](https://go.microsoft.com/fwlink/?LinkID=613727)
==============================================================================

Also the 2 hours timeout was not enought in this build.

Edit #2

I setup a test series and now I could say: it seems that the first sheduled build of a day run into a timeout. Only why is unclear.

enter image description here

The screenshot shows a series of shedueld builds. The source and the tasks are the same for all builds.

 1. 10:00 AM -> Timeout
 2. 00:55 AM (Next Day)
 3. 03:00 AM
 4. 05:05 AM

I make similar observations before, but this one I could put perfectly in one screenshot. How is this possible?

Mar Tin
  • 2,132
  • 1
  • 26
  • 46
  • Can you increase the timeout? – Shayki Abramczyk Dec 03 '19 at 07:03
  • Yes, of cause I could do that. But what is the reason for the delay? A Manual build takes about 7 minutes. If I have multiple nightly builds on, lets say 20 Pipelines, I would need a lot of agents to run it nightly. – Mar Tin Dec 03 '19 at 07:05
  • I really don't know :/ – Shayki Abramczyk Dec 03 '19 at 07:08
  • 1
    I will increase the timeout, to observe the total time consumption for the next days. If you have any idea to get more informations about the reasons, you are very welcom. :-) – Mar Tin Dec 03 '19 at 07:11
  • 1
    What is your project type? SSIS project? I saw you are calling `devenv` to rebuild. Also, you are calling `devenv.com` or `devenv.exe` to do this rebuild? As the similar issue we received before, this seems does not relevant with schedule and manual. You can try a troubleshooting method that let a schedule build run after one manual build. Because, as I know, it will take a very long time to start the `devenv` at first run, but if you run it again just after it, it will very fast. – Mengdi Liang Dec 03 '19 at 13:09
  • @MerlinLiang-MSFT sorry the project type is C# desktop application. The task call **devenv.exe**, `devenv $filePath /Rebuild "$ProjectConfig" /Out $logPath | Out-Null`. But wait, I check out my devenv environment path and as result I get: `where devenv >>> C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\devenv.com >>> C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\devenv.exe`. So what do you prefer `.exe` or `.com`? – Mar Tin Dec 04 '19 at 05:28
  • 1
    @MarTin, Since your project is a C# desktop application, I'd better suggest you use `msbuild` to do this rebuild. On my own opinion, `devnev.exe` is a least recommended way because it need longer time than `.com` and `msbuild`. Could you try with using `msbuild` to see whether it would be timeout? – Mengdi Liang Dec 04 '19 at 07:26
  • @MerlinLiang-MSFT Thanks for your advice. I realize your recommendation and replace the custom task with the Visual Studio Build Task which useing MSBuild. I have first results, but I will observe the behavior for the next days and then I publish them here. – Mar Tin Dec 05 '19 at 05:52
  • @MerlinLiang-MSFT I wrote an edit. The example image shows a time consuption from the **Visual Studio-Build** task (MSBuild) for **41 min** and **Vs-Test** task with over 55 min. Than the 2 hour timeout throw the build. – Mar Tin Dec 06 '19 at 07:27
  • @MarTin, Too odd. Do you mind share 3 debug logs to me? I want to involve our team to analyze and investigate this. One is the schedule log which is cancelled by timeout. Second is the manual one which executed very quick. The last log I want get is which you are using VSbuild and VStest. In addition, what's your test type? UI test? – Mengdi Liang Dec 06 '19 at 07:51
  • Unfortunately I don't know exactly what you need in the third log. Do you mean I should execute **VSbuild/VStest** outside from the TFS and generate the log manually? Our test type is currently about 500 UnitTests only. No special tests included. We are still in a TFS test-phase. – Mar Tin Dec 06 '19 at 10:24
  • @MarTin, Because we want to compare the differences between these different scenario. For the third log, as you mentioned, it timeout at test step, want to get which lead it, and compare it with others. As normal, 500 unit tests should not lead this. – Mengdi Liang Dec 06 '19 at 14:14
  • You can read me like a open book. Currently I talk to our management, as a simple devoloper, I am not able to decide by my self. Personally I see no probleme here, but I need a permission. So I am realy sorry for the late answer and the delay. I hope I get a response in the next days. I keep you up to date. Thanks for all. – Mar Tin Dec 10 '19 at 05:43
  • @MarTin. Sure. I understand the worry about security. Just let me know what you worried, and I would suggest you the best way which could involved our team. We need logs to see that why they are wasting too much time here, and why they are action so different. Then maybe need get some more IIS log from our backend database to analyze it. – Mengdi Liang Dec 11 '19 at 10:49
  • @MerlinLiang-MSFT is it possible to contact you per mail? – Mar Tin Dec 12 '19 at 11:36
  • @MerlinLiang-MSFT I edit my OP with a important cognition. Maybe you oberserve a similary behavior before? – Mar Tin Dec 13 '19 at 06:00
  • @MerlinLiang-MSFT We still suffering of the issue. Do you have some updates? – Mar Tin Jan 13 '20 at 12:05

0 Answers0