Deployment failed due to invalid state

I am getting the following error in case I push 2 commits in a very small duration. The first commit gets deployed successfully, however, the second commit fails because the EBS state from the first commit is still not in the ready state.

Is there any potential solution to this problem?

[error]Deployment failed: Error: Status: 400. Code: InvalidParameterValue, Message: Environment named bis-prod is in an invalid state for this operation. Must be Ready.

Here is the script I am using

 - name: Beanstalk Deploy
      uses: einaregilsson/beanstalk-deploy@v9
      with:
        # AWS Access Key
        aws_access_key: {{my-key}}
        # AWS Secret Key
        aws_secret_key: {{my-secret}}
        # AWS Region
        region: us-west-1
        # Beanstalk application name
        application_name: {{app-name}}
        # Beanstalk environment name
        environment_name: {{my-env}}
        # Version label for new Beanstalk version
        version_label: "${{ steps.timestamp.outputs.date }}"
        # Zip file with the version to deploy. If skipped the action will deploy existing version.
        deployment_package: {{package-name}}
        # If set to "true" then the action will deploy an existing version with the given version_label if it already exists, but otherwise create the version and deploy it.
        use_existing_version_if_available: false
        # Whether the action should wait for the deployment to finish and log status messages during the wait. Default is "true". If set to "false" the action will start the deployment on Beanstalk and then exit.
#         wait_for_deployment: # optional
        # How many seconds to wait for the environment to return to Green state after deployment is finished. Default is 30 seconds.
        wait_for_environment_recovery: 600

[einaregilsson]

Closing this issue, don’t think it’s a fix that should be made in an individual action, rather it’s a change that GitHub would have to do in how their actions are scheduled.

[dnorth98]

This is an underlying issue with GitHub actions rather than this specific action (and it’s the only thing keeping me moving all our deployments to GH actions). Almost all CI/CD systems will queue executions from the same branch…alas, GH actions doesn’t. And as noted, any solution which “busy-waits” is just burning minutes.

It’s too bad, this action is brilliant but can’t work in a fast paced environment with many commits being merged to a mainline within a short duration of each other