[pothos]

For rerunning a failed CI job the generated image name can be the same when the commit ID didn't change. In this case it is good to reuse the existing AMI. Add an option that allows that. The other mode would be deleting the existing one first which makes sense if the image version is not git hash based, but this is not added for now.

[martinpitt]

TBH this feels a bit too unpredictable to me. If the git SHA is part of the name, then the new would-be-rebuilt AMI should be identical to the existing one. But in many cases it isn't -- if the name is built from a tag (they can move) or a date, or even something generic like --name myproject-stage, then --reuse would silently keep the old one. I also had one case in CI were the AMI was actually broken, and a delete/rebuild helped (it was in an early experimentation stage, and I didn't dig into the details).

My preference would be to instead have an option (--replace?) that deregister-images an AMI of the same name if it exists. It may be a bit more expensive for the "my AMI name encodes the content, and my test is flaky" case, but correct/more robust for "nightly build with predictable name" case.

WDYT? If you feel strongly, I don't veto it, but I would at least like to discuss the alternative. Thanks!

[pothos]

+1 I'm always in favor of making sure we have the right thing, thus --replace is nicer. I just saw that the current CI action didn't have the rights to deregister and wondered whether this is to prevent deleting things owned by something else (and then being able to overwrite it).

A workaround for now is also to not rerun the CI action but push an modified commit.

[martinpitt]

@pothos right, I only gave it the minimal privileges for what it does today. But I think at least for our dev account we need to introduce deletion permission (restricted to some tags) for cleaning obsolete AMIs; they pile up too quickly right now. That's why I recently added a "best-before" validity and extra tags. Once that's in, a --replace option should work as well.