feat: Add support for the forceNewDeployment parameter in the update_service function

[geoL86]

Summary
Feature request: Add support for the forceNewDeployment parameter in the update_service function.

Motivation
Currently, there is no way to explicitly trigger a new deployment of an ECS service when there are no changes to the task definition or service configuration. Adding support for the forceNewDeployment parameter would enable users to manually initiate a new deployment—useful in cases like re-pulling the latest image with the same tag.

Proposed Change
Introduce an optional forceNewDeployment parameter to the update_service function, defaulting to false. When set to true, the ECS service will trigger a new deployment regardless of detected changes.

[fabfuel]

Hi Leonid,

ecs-deploy always creates a new task definition revision, even if there are no changes.

This - so far - always triggered a new deployment. Did AWS change that behavior for you? Your service is updated, using the new task definition revision, but it's still running the old revision? I have not yet seen this behavior.

Can you confirm, that if you just run ecs deploy <cluster> <service> the task definition revision in the service does not change or the service is running old revisions?

Best
Fabian

[geoL86]

Hi Fabian,

First of all, thank you for the project and the quick response. I will give an example of what we encounter from time to time on our project.

We build images and classically store them in the ECR repository with the tag (with some normalizing and modifications): branch_name + commit_hash As a result, it looks something like this: 1111111111.dkr.ecr.eu-central-1.amazonaws.com/backend-production:master-709937ed8e67a254841bb7597101964e5ff7f287

Yes, you are right, building and deploing new version of our code using the following command: ecs deploy -t <IMAGE_TAG> --timeout 1800 --rollback --no-deregister <CLUSTER_NAME> <SERVICE_NAME> will create new Task Definition revision and deploy ECS service according to the our needs. But only when there are actual changes in the code and we can track them by commit.

Also, sometimes, when building an image, we have some dynamic data that is included in the build process, such as translations, etc. Technically, this is not a new code release. And again, restarting the build pipeline will do everything pre-built and perfectly, but the tag remains the same and we run the release with the command mentioned above. Which yes, will create a new revision, but the image and its tag will be the same. But when building the image and sending it to the repository with the same tag, a new digest (sha256) is created and, according to the Container image resolution and Version consistency, new service tasks will be launched with the existing digest - despite the fact that the digest(top one) for our tag has changed.

Given all this, the best solution would be to use the forceNewDeployment parameter, which has long been available for use and will help in the current case.

p.s. Yes, we don't use tag mutability: https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-tag-mutability.html

Best regards,
Leo