CircleCI-Public / aws-ecs-orb

An orb that simplifies deployment to Amazon's Elastic Container Service (ECS). Supports both EC2 and Fargate launch types.
https://circleci.com/orbs/registry/orb/circleci/aws-ecs
MIT License
51 stars 80 forks source link

verification-timeout parameter is ignored in aws-ecs/update-service command #133

Closed vatima2016 closed 2 years ago

vatima2016 commented 3 years ago

Orb version:

2.2.1

What happened:

verification-timeout parameter is ignored in aws-ecs/update-service command. B/G deployment verification times out always in 10 minutes e.g. in case of a defect task configuration.

- &deploy-service-update
    executor: python3
    steps:
      - *attach_project_workspace
      - *setup-aws-vars
      - aws-cli/setup
      - aws-ecs/update-service:
          # ECS or CODE_DEPLOY, env vars are not allowed, because the parameter expects enum value :-(
          deployment-controller: CODE_DEPLOY
          cluster-name: "${ECS_CLASTER_ID}"
          codedeploy-application-name: "${CODE_DEPLOY_APPLICATION_NAME}"
          codedeploy-deployment-group-name: "${CODE_DEPLOY_DEPLOYMENT_GROUP_NAME}"
          codedeploy-load-balanced-container-name: "${CONTAINER_NAME}"
          codedeploy-load-balanced-container-port: 8180
          container-image-name-updates: "container=${CONTAINER_NAME},tag=${CCI_PROJECT_VERSION}"
          container-env-var-updates: "container=${CONTAINER_NAME},name=SPRING_PROFILES_ACTIVE,value=aws,container=${CONTAINER_NAME},name=SPRING_MYTS_DATASOURCE_JDBCURL,value=${SPRING_MYTS_DATASOURCE_JDBCURL},container=${CONTAINER_NAME},name=SPRING_MYTS_DATASOURCE_DRIVERCLASSNAME,value=org.h2.Driver,container=${CONTAINER_NAME},name=SPRING_MYTS_DATASOURCE_USERNAME,value=${SPRING_MYTS_DATASOURCE_USERNAME},container=${CONTAINER_NAME},name=SPRING_MYTS_DATASOURCE_PASSWORD,value=${SPRING_MYTS_DATASOURCE_PASSWORD}"
          family: "${CONTAINER_NAME}-vti-test"
          # The name of the service to update. If undefined, we assume `family` is the name of both the service and task definition.
          service-name: "$ECS_SERVICE"
          force-new-deployment: false
          verify-revision-is-deployed: true
          # B/G deployment
          # termination in CodeDeploy deployment group must have lower value, e.g. 5 minutes, which should be OK in combination with the default verification timeout
          # seems not to work, default is 10m:
          verification-timeout: 30s
          fail-on-verification-timeout: true

Expected behavior:

B/G deployment verification should timeout as specified in 30 seconds

Additional Information:

B/G deployment verification times out in 10 minutes, so the parameter seems to be ignored.

https://support.circleci.com/hc/en-us/articles/360007188574-Build-has-hit-timeout-limit

You can see in the source code that no_output_timeout is not aligned with the according command key. Could this be the reason? https://github.com/CircleCI-Public/aws-ecs-orb/blob/master/src/commands/update-service.yml

  - when:
      condition:
        equal:
          - CODE_DEPLOY
          - << parameters.deployment-controller >>
      steps:
        - run:
            name: Update ECS Blue/Green service with registered task definition.
            command: <<include(scripts/update-bluegreen-service-via-task-def.sh)>>
            environment:
              DEPLOYMENT_CONTROLLER: <<parameters.deployment-controller>>
              ECS_PARAM_CD_APP_NAME: <<parameters.codedeploy-application-name>>
              ECS_PARAM_CD_DEPLOY_GROUP_NAME: <<parameters.codedeploy-deployment-group-name>>
              ECS_PARAM_CD_LOAD_BALANCED_CONTAINER_NAME: <<parameters.codedeploy-load-balanced-container-name>>
              ECS_PARAM_CD_LOAD_BALANCED_CONTAINER_PORT: <<parameters.codedeploy-load-balanced-container-port>>
              ECS_PARAM_VERIFY_REV_DEPLOY: <<parameters.verify-revision-is-deployed>>

      no_output_timeout: << parameters.verification-timeout >>

I don't know whether there could be a dependency to https://github.com/CircleCI-Public/aws-ecs-orb/issues/115 in cases when the desired timeout exceeds the default one.

geoL86 commented 2 years ago

I can confirm, we observe the same issue on our pipeline.

brivu commented 2 years ago

This is solved with PR #163