Ability to config Pipeline to source from ECR repository

[ShanikaEdiriweera]

It would be great if there is a config like below.

source:
  # The name of the provider that is used to store the source artifacts.
  provider: ECR
  # Additional properties that further specify the location of the artifacts.
  properties:
    tag: latest
    repository: <erc-repository-url>

[Lou1415926]

Thanks for the feature request @ShanikaEdiriweera ! Makes a lot of sense to me 👍🏼 I have a few questions if you don't mind 👀 :

1. I guess your service manifests have image.location: <erc-repository-url>:latest, instead of image.build. Am I guessing right?
2. Are all of your services like that ⬆️ ?
3. For the services that have image.location: <erc-repository-url>:latest, is the behavior the same across all environments? i.e. do you have A or B:

# A
environments:
  prod:
    image:
      location: <erc-repository-url>:latest
  test:
    image:
      build: Dockerfile # the `test` environment however builds from Dockerfile

# B
environments:
  prod:
    image:
      location: <erc-repository-url>:latest
  test:
    image:
      build:  <erc-repository-url>:latest # Both prod and test is grabbing an existing image.

4. Are you currently using copilot svc deploy --force to update your service?
5. Finally, if we support a pipeline that gets triggered on ECR push - do you expect the pipeline to be release application code change only? Say, if you have to change an infra config (say the count or cpu in manifest), you expect to deploy this change through another pipeline dedicated to infra, is this correct?

[ShanikaEdiriweera]

Thanks for the feature request @ShanikaEdiriweera ! Makes a lot of sense to me 👍🏼 I have a few questions if you don't mind 👀 :

1. I guess your service manifests have image.location: <erc-repository-url>:latest, instead of image.build. Am I guessing right?
2. Are all of your services like that ⬆️ ?
3. For the services that have image.location: <erc-repository-url>:latest, is the behavior the same across all environments? i.e. do you have A or B:

# A
environments:
  prod:
    image:
      location: <erc-repository-url>:latest
  test:
    image:
      build: Dockerfile # the `test` environment however builds from Dockerfile

# B
environments:
  prod:
    image:
      location: <erc-repository-url>:latest
  test:
    image:
      build:  <erc-repository-url>:latest # Both prod and test is grabbing an existing image.

4. Are you currently using copilot svc deploy --force to update your service?
5. Finally, if we support a pipeline that gets triggered on ECR push - do you expect the pipeline to be release application code change only? Say, if you have to change an infra config (say the count or cpu in manifest), you expect to deploy this change through another pipeline dedicated to infra, is this correct?

Thank you for the response! Please find answers below.

1. Yes
2. I have one service for now. Other services also can be like that.
3. I have only one env atm. But will be the same.
4. Yes
5. Yes only app changes. will have a separate pipeline for infra

[Lou1415926]

Sweet. Thanks for your response - it helps a lot!

I just realized you also posted a discussion thread https://github.com/aws/copilot-cli/discussions/4905 in which you mentioned that your code source is GitLab.

This is just a note for the Copilot core dev team - another "universal remedy" is for us to support S3 bucket as Source provider, which can be a workaround for basically any other source provider that are not natively supported yet, including GitLab. Related: https://github.com/aws/copilot-cli/issues/4805

Based on your response though, I agree that ECR is the better solution for you! Thanks for reaching out ❤️

[ShanikaEdiriweera]

Cool. For now I used Gitlab mirroring config to mirror my repo to CodeCommit and then build the copilot pipeline using that.

[VaZark]

Has this been abandoned?

In a similar case, I run tests on Github and would like to push to ECR only if the tests pass (and thus trigger deployment). This way, ECR / Copilot cares only about the deployment, meanwhile everyone can see the state of the build with GH actions. It helps us avoid configuring alerts/provisioning access to AWS for everyone on the team.