First Deploy Works, Second Deploy Fails about aws-toolkit-azure-devops

[ryanmord]

I was able to get around this by changing the EC2 instance size from t1.micro to t2.micro. I saw some notice about the instance utilizing high amounts of memory prior to the deployment failing so I gave a larger instance size a shot and it worked.

[normj]

I haven't been able to reproduce the problem. In the console or toolkit can you snapshot the logs and post that. That feature will grab logging information from other sources on the instance that might give clues into why it failed.

[Neuroforge]

This is great. Blew away my box to rebuild.

Now it has worked for 3 builds. Then boom! It breaks again.

Appears to be random.

TailLogs-1507682279.txt

First error appears to be....

Could not move C:\cfn\download_version_bundle.ps1.bak2 to C:\cfn\download_version_bundle.ps1.bak
2017-10-11 00:20:24,020

Any advice would be appreciated.

[stevejroberts]

We've contacted the Elastic Beanstalk team to see if they have any insights as to what might be causing the fails. When we hear back we'll update the issue.

[normj]

Is there anything special about the BlueHeronV3.dll file? Like is it a native dependency that is being pinvoked or does it have open file handles or anything? I'm trying to understand why IIS and msdeploy aren't able to unload that file.

[Neuroforge]

Hello.

I am using .NET Core. BlueHeronV3.dll is the application that i have created.

If i use Visual Studio Tools for AWS the site deploys regularly and consistently.

It is only when using VSTS that this error occurs.

[normj]

I still haven't been able to reproduce the issue but after looking at the code differences between VS Toolkit and the VSTS I have a theory that I'm confirming with the Beanstalk team.

[Neuroforge]

Awesome. It is intermittent.

Let me know though. As i'd like to get my CI pipeline working again.

Thank you!

[stevejroberts]

Neuroforge@, we're still looking into this and have a theory as to what is happening. Wondered if you could help us out in getting the request id and header data for the calls the task is making to Beanstalk to help us when working with the service team?

On Monday we shipped v1.0.8 of the tools and each task now has a set of diagnostic switches that will dump the request and response headers plus the unique request id the service gives to the call. After install, if you edit your Beanstalk task you'll see the two new switches in a collapsed 'Diagnostics' section toward the bottom of the configuration page.

Having selected both options, if you then toggle the 'system.debug' flag for your pipeline to 'true' and run the build, the debug log will contain the data we need in sections like this (there will be one section per Beanstalk api call):

2017-10-25T17:20:31.7568720Z ##[debug]AWS describeApplications request ID: b6793381-ffbf-433a-b3fa-db03e20dd751
2017-10-25T17:20:31.7568720Z ##[debug]---Request data for b6793381-ffbf-433a-b3fa-db03e20dd751---
2017-10-25T17:20:31.7568720Z ##[debug] Path: /
2017-10-25T17:20:31.7568720Z ##[debug] Headers:
2017-10-25T17:20:31.7568720Z ##[debug] User-Agent=aws-sdk-nodejs/2.94.0 win32/v6.10.3 promise
2017-10-25T17:20:31.7578722Z ##[debug] Content-Type=application/x-www-form-urlencoded; charset=utf-8
2017-10-25T17:20:31.7578722Z ##[debug] X-Amz-Content-Sha256=111d4e7c5490bd4a1b03b6d2ac581fdf974304376985324b9e40235c40114a07
2017-10-25T17:20:31.7578722Z ##[debug] Content-Length=90
2017-10-25T17:20:31.7578722Z ##[debug] Host=elasticbeanstalk.us-west-2.amazonaws.com
2017-10-25T17:20:31.7578722Z ##[debug] X-Amz-Date=20171025T172030Z
2017-10-25T17:20:31.7578722Z ##[debug] Authorization=AWS4-HMAC-SHA256 Credential=********/20171025/us-west-2/elasticbeanstalk/aws4_request, SignedHeaders=host;x-amz-content-sha256;x-amz-date, Signature=5608099abd088bfaffab832ea55fe27ac66de8089225572a77bbf7f04b7946ee
2017-10-25T17:20:31.7578722Z ##[debug]---Response data for request b6793381-ffbf-433a-b3fa-db03e20dd751---
2017-10-25T17:20:31.7578722Z ##[debug] Status code: 200
2017-10-25T17:20:31.7578722Z ##[debug] Headers:
2017-10-25T17:20:31.7578722Z ##[debug] content-type=text/xml
2017-10-25T17:20:31.7578722Z ##[debug] date=Wed, 25 Oct 2017 17:20:31 GMT
2017-10-25T17:20:31.7578722Z ##[debug] x-amzn-requestid=b6793381-ffbf-433a-b3fa-db03e20dd751
2017-10-25T17:20:31.7578722Z ##[debug] content-length=1658
2017-10-25T17:20:31.7578722Z ##[debug] connection=keep-alive

Would you mind grabbing the data and posting it here? There is no personally identifiable or confidential data in the output.

I had the same problem. Thanks to the hint from @ryanmord about the memory usage I got it running without actually upgrading the instance. Since I'm just developing a testing website for now, I could connect via RDP and stop the website in the IIS (developing a .Net Framework website). After that I could deploy again.

Of course this makes only sense if you're in development and fine connecting manually via RDP every time.
For production this is not a feasible solution.

[PrathameshSaviant]

Thanks to @ryanmord.. just upgrading t1.micro to t2.micro worked!!!

[hunterwerlla]

Closing due to inactivity and fixed issue

[abelfleitas]

The problem continues for me, I have a t2.micro instance, when I run the pipeline I get the same error.
First time works second time doesn't,
I've searched everywhere and can't find a way to fix it.