EB always deploying the latest version, no matter which version selected

0

Our setup:

two different applications

build server uploading new packages to S3 and creating new EB versions via PowerShell

multiple environments per application

we usually trigger deployment from the "Application Version" page in AWS Console

This worked very well for hundreds of deployments so far, but today, it somehow got messed up (for both EB applications at the same time!):

let's say I deploy version label v123 to environment A, while there is already v125. The deployment succeeds according to the environment events, and the intended version is reflected in the Application Version table as well as the environments overview.

However, no matter what version I selected, the actually deployed version will always be v125. Once there is a v126, it will always be v126. Even if the selected version had been deployed before, or is still running in (untouched) environments. (The version number is also stored inside the zipped package.) At least it doesn't mix up the versions between EB applications.

Also, when downloading the source package from the Application versions view, I always get the latest uploaded package for this application, not the one I clicked.

How can we get out of this situation? And what might be triggering it?

Two thoughts on possible reasons:

The object key for new versions in S3 is always the same (per application) in our case. Is this supported, or should be name it differently for each version? On the other hand, it had worked like that for a long time...

Before the problem started, we updated one of the environment's configuration via AWS Console, Configuration | Software | Modify... Previously, we had done this most of the time using PowerShell (Update-EBEnvironment). Is this known to cause problems?

asked 5 years ago184 views
1 Answer
0

Using a unique object key in S3 for every new build solved the problem for us so far (but only for new builds, after making this modification in our build and deployment pipeline).

This requirement should be documented, or even better, using unique object keys should be enforced, instead of breaking unsuspectingly after months of use!

answered 5 years ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions