question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Option to use existing version if present, otherwise upload deployment-package

See original GitHub issue

From the readme:

You can also use the action to deploy an existing version. To do this simply omit the deployment-package input parameter. The action will then assume that the version you pass in throught version_label already exists in Beanstalk and attempt to deploy that.

I am interested in a solution to the situation where the desired behavior is to:

  1. use the already deployed version if it exists
  2. otherwise, create the version from deployment-package

Basically, ignore deployment-package if the version already exists on s3.

This would address the following error that occurs if you deploy to multiple environments as demonstrated in https://github.com/einaregilsson/beanstalk-deploy/issues/5#issuecomment-571128797:

Deployment failed: Error: Version XXXX already exists in S3!

In our case, XXXX is the source commit hash, so we don’t have to worry about version being ambiguous.

Issue Analytics

  • State:closed
  • Created 4 years ago
  • Comments:8 (4 by maintainers)

github_iconTop GitHub Comments

1reaction
dhimmelcommented, Jan 26, 2020

Could possibly add some kind of optional use_existing_version_if_available: true or something like that

I think the option makes sense for backwards compatibility and out of precaution… I could imagine situations where users don’t intend to create a duplicate version number and perhaps the failure would be good in that case.

OTOH there are presumably few users currently, so backwards incompatibility probably is not a huge deal. And given the usefulness of this action, I presume it will have many more users in the future. So not a bad time to make changes.

Anyways no strong opinion here. Whatever form it’s implemented, I think it’d be useful!

0reactions
einaregilssoncommented, Feb 9, 2021

@juan-ntsprint Thanks, I’ll add that to the docs 🙂

Read more comments on GitHub >

github_iconTop Results From Across the Web

Manually deploy software updates - Configuration Manager
Select deployment package: Choose this setting to select an existing deployment package for the software updates that are in the deployment.
Read more >
Deploying applications to Elastic Beanstalk environments
Use the on-screen form to upload the application source bundle. Choose Deploy. Redeploying a previous version. You can also deploy a previously uploaded...
Read more >
Compare Deployment Packages - Appian 22.2
This page describes how Appian compares a deployment package to the existing application in a target environment. This package comparison allows you to ......
Read more >
Managing software - Tanium Documentation
Use software packages to install, update, or remove software on a set of ... the Self Service display name and icon to upload...
Read more >
Deploying with the Serverless Toolkit - Twilio
It will list all options you have available. Replicating an existing deployment. Aside of deploying code to an environment by uploading everything again,...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found