Git parameters superfluous when image is hard coded

[geod]

Hi,

Template very useful Thanks.

One issue when trying to re-use

1. ecs-refarch-continuous-deployment.yaml has a bunch of parameters to supply your own repository. But .... within templates/service.yaml the amazon image is hard coded. When you switch to providing your own github project as parameters it actually has no effect (the amazon namespace is universally available in docker-hub. So what happens is you build your own project then use the amazon image at the last stage =) )

ContainerDefinitions:
        - Name: simple-app
          Image: amazon/amazon-ecs-sample
          EntryPoint:

I think it needs to be a parameter

2. Second suggestion is not to override the entry point as part of the task def and allow the entry point provided as part of docker image to run by default

G

[jpignata]

The GitHubRepo is used to configure the pipeline -- the initial task definition that has the Docker image configured is just a placeholder until the pipeline's first execution. Make sense?

I don't know about your second point - I think I took the task definition whole cloth from here. What's the benefit of changing it?

[geod]

Thanks for quick response

1. Think there may have been two things going on. My deploy stage of the pipeline was still running at 35 minutes. When I hit the service I saw the 'hello world' page from the amazon/amazon-ecs-sample image. I assumed I had not replaced something correctly (rather than it being a default until the pipeline runs). Is it more intuitive to have the container blank till the first deploy?

Is there repetition in having the task-def defined in both the the task-def.json in addition to the cloud formation template?

2. I guess my question is whether the task-def from git will replace the cloud formation specification once the first pipeline runs.

[jpignata]

I'm not sure why your pipeline would be running for 35 minutes. DId it ever complete successfully?

As to the intuitive question - I'm not sure. CloudFormation requires the service to come up healthily and since we're deploying this service, using its configuration seemed natural. The instructions mention to commit a change to the index to watch it go through the pipeline which was is the intent of the reference architecture.

In this pipeline, the only thing that changes is the image field in the task definition via CodePipeline. The task definition in git is not used.

[geod]

I'm not sure why your pipeline would be running for 35 minutes. DId it ever complete successfully?

To begin with I replicated using the launch stack from the page so I know it is me not you =). The only change I have made are running under a different account and also from the command line as opposed to console. I killed it after 35 minutes so it did not get a chance.

The task definition in git is not used.

Thanks. Was grepping to understand if it had an impact.

Thanks for your help - will close this one