copilot-cli icon indicating copy to clipboard operation
copilot-cli copied to clipboard

seeking advice on CI/CD for `copilot env deploy`

Open codekitchen opened this issue 3 years ago • 2 comments
trafficstars

Hey all, we deploy our copilot applications using GitHub Actions calling out to copilot deploy rather than using copilot pipeline features. With the new env manifest features in v1.20, I've noticed that copilot deploy alone is no longer enough to apply all possible updates in CI/CD -- if you modify an environment manifest, you also have to run copilot env deploy. In addition this applies to some copilot version upgrades too -- for instance in v1.21 the lambda functions were updated from node v12 to v16, and that update isn't applied to our environments until I explicitly run copilot env deploy.

I'm looking for some advice on how best to integrate copilot env deploy into our CI/CD workflows.

  1. We could run it before every copilot deploy just in case anything has changed, but it fails if there are no environment changes to apply -- I think we'd need to grep the output looking for a string such as "Your update does not introduce immediate resource changes" to differentiate between an actual failure and there being no changes.
  2. We could do copilot env deploy --force but I'm a little wary of running that on every deploy, is that a good idea? This is also pretty slow, it takes about a minute in my testing even if there are no changes.
  3. We could set up our workflows to only run copilot env deploy when the env manifest is modified, but that will miss potential environment changes due to copilot version upgrades or other external factors.

Maybe a feature could be added to copilot env show json output to indicate if there are any env changes to apply?

codekitchen avatar Aug 19 '22 22:08 codekitchen

Hey @codekitchen! My recommendation would probably be option 2 - I can't think of any unintended side-effects of running --force on every deploy, other than it takes a little bit longer. --force just updates the output LastForceDeployID on the environment stack to a random ID.

I wonder if a nice solution would be to have Copilot exit with 0 instead of 1 on copilot svc/job/env deploy if there are no changes.🤔 Would that make it so that option 1 works for you, without having to parse the output?

dannyrandall avatar Aug 19 '22 23:08 dannyrandall

Thanks! I wasn't sure what the actual mechanism behind --force was, that sounds fine for now.

I wonder if a nice solution would be to have Copilot exit with 0 instead of 1 on copilot svc/job/env deploy if there are no changes.🤔 Would that make it so that option 1 works for you, without having to parse the output?

I love that idea, that would be great. We've contemplated looking into adding --force to our svc deploy, since there's some edge cases where a deploy can run with no changes and end up erroring. Exiting success on no-op deploys would solve that as well.

codekitchen avatar Aug 20 '22 00:08 codekitchen

Thank you for bringing it up. Have you found a good mechanism to avoid unnecessary deployments in Github Actions? I only want to deploy if there either changes in:

  1. Container image
  2. Manifest file

However, we have a monorepo with multiple projects and my current approach is to allowlist certain paths of the repository to start a deployment job. It's error-prone and I would like to always run the deployment job, but exit earlier if no changes are available.

coding-velociraptor avatar May 09 '23 10:05 coding-velociraptor