search

jenkinsci / aws-beanstalk-publisher-plugin

Jenkins AWS Elastic Beanstalk Publisher
https://plugins.jenkins.io/aws-beanstalk-publisher-plugin/
MIT License
13 stars 17 forks source link

Skip version creation if version exists #35

Open Hildebrand opened 8 years ago

Hildebrand commented 8 years ago

Hi David,

I've set up a nice Jenkins pipeline that eventually deploys to Beanstalk using your plugin. The thing is that when trying to deploy a previous version, Beanstalk fails with the following error because the version already exists.

java.lang.RuntimeException: com.amazonaws.AmazonServiceException: Application Version breeze_7 already exists. (Service: AWSElasticBeanstalk; Status Code: 400; Error Code: InvalidParameterValue; Request ID: d33c06b5-8590-11e6-8184-a350bc8b5a45)

I guess it would make sense to add a (n optional) check whether the version already exists, and if so, only runs the update-environment command to roll back to this previous version.

Would this be feasible?

Thank you, Hildebrand

DavidTanner commented 8 years ago

I am not sure on this. If the version name already exists should it just use the existing version? I think that may be an unexpected behavior. For us, we use the promotion plugin and just tell it which version to use on EB, without uploading to S3 and creating the version.

Hildebrand commented 8 years ago

Yes, if the version name already exists it should just use the existing version yes. Why would it be unexpected behaviour? It would be the same as selecting a version from the application version overview in AWS right?

Could you please tell a bit more on how you upload a version to S3 and create a version, and separately deploy this new version?

If I'm not mistaken your plugin currently allows one to deploy a version without S3 + version creation, but not the other way around, i.e. only pushing to S3 and creating a new version. This would allow me to first create the S3 + version and in a later build task deploy this to different environments, and possible running this again at a later point in time to revert to an older version.

DavidTanner commented 8 years ago

This would work as a configurable option, that way for those expecting a new version with every build won't be broken.

Hildebrand commented 8 years ago

Do you expect to be able to implement this in the coming time, or do you suggest to fork and implement this ourselves?

DavidTanner commented 8 years ago

I suggest you fork the project and make the changes, then make a pull rarest back to here.

lorenh commented 1 year ago

I realize this is an ancient thread, but did anyone ever take this work on? We have the same scenario as Hildebrand where we upload to S3 once, and promote same package to different environments, so the failure encountered when the version already exists needs to be able to be configured to be non-fatal.