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

[dhimmel]

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 #5 (comment):

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.

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

Hmmm, interesting. I can see that it would be useful for some cases, but adds some complexity. So your use case is you're deploying the same build to two environments, and only want to create the version once and then deploy to both? Wouldn't a simple workaround being defining two tasks, where the first creates the version and deploys to env 1 and the second deploys the existing version to env 2?

[dhimmel]

We are deploying to staging or production based on monitoring commit messages. If a commit message contains [deploy staging], we want to deploy to staging. If the commit message contains [deploy production] we want to deploy to production.

Our workflow is like:

    - name: deploy to staging
      if: contains(github.event.head_commit.message, '[deploy staging]')
      uses: einaregilsson/beanstalk-deploy
      with:
        environment_name: staging
        version_label: ${{ github.sha }}
        deployment_package: src/deploy.zip
    - name: deploy to production
      if: github.event_name == 'push' && contains(github.event.head_commit.message, '[deploy production]')
      uses: einaregilsson/beanstalk-deploy
      with:
        environment_name: production
        version_label: ${{ github.sha }}
        deployment_package: src/deploy.zip

This works fine, unless the commit message be like:

[deploy production]
[deploy staging]

In this case, [deploy staging] will fail because the version already exists.

I could imagine a similar issue arising if we were to git reset --hard to a prior commit, and rerun the CI to redeploy it.

Basically, it seems like there could be a range of situations where a version already exists but the workflow step doesn't actually know if it does.

[dhimmel]

One workaround would be adding a timestamp to version_label, but then we'd lose all efficiency gains by not having to store the same content twice.

I kinda wish I'd done it like you said from the beginning. But now I'm thinking whether to add the feature directly, or add it as some kind of option. Could possibly add some kind of optional use_existing_version_if_available: true or something like that.

[dhimmel]

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!

I've just published v5 of the action which adds this parameter, use_existing_version_if_available . Set it to true to get the desired behaviour. Let me know if there are problems with it 🙂

[juan-ntsprint]

Just FYI, I just tested that attaching AWSElasticBeanstalkWebTier and AWSElasticBeanstalkService managed policies to the user is enough for a successful deployment.

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

[Aladdin4u]

I'm having the same problem, will I have to keep emptying and deleting S3 bucket if a deployment goes wrong