this is the same image as 0.12-staging, just re-tagged for prod.

Two questions:

1. What's "retagging" mean and why was it necessary here?
2. Is it possible to use the same image for both staging and prod, like we used to?

1. What's "retagging" mean and why was it necessary here?

it means i ran docker tag commapp/identity-server:0.12-staging commapp/identity-server:0.12. i did it so that on prod, the image tag would appear as "0.12"

2. Is it possible to use the same image for both staging and prod, like we used to?

0.12-staging and 0.12 are the same image. if you're asking if we can remove the ternary from line 2 and just have a single tag "0.12" for both, yes, we definitely can. realize i introduced a process change in D11260 without really discussing it... sorry about that

here's why i prefer this process, though:

1. it's safer. assuming that devs remember to revert to master after testing local changes, we can make sure that things work on staging for a short period before we apply changes to prod. there's no good way to test landed changes for an extended period in the current process without running the risk of a) another dev undoing the changes while testing something on a custom tag or b) the changes being applied prematurely to prod
2. we can see the delta between staging and prod clearly. before, it was possible for staging to be a few releases ahead of prod without any visibility. this is a good (albeit not perfect) forcing function to make sure we keep prod up to date with staging

lmk what you think. curious for @bartek and @will 's thoughts too

In D11305#326479, @varun wrote:

1. it's safer. assuming that devs remember to revert to master after testing local changes, we can make sure that things work on staging for a short period before we apply changes to prod. there's no good way to test landed changes for an extended period in the current process without running the risk of a) another dev undoing the changes while testing something on a custom tag or b) the changes being applied prematurely to prod
2. we can see the delta between staging and prod clearly. before, it was possible for staging to be a few releases ahead of prod without any visibility. this is a good (albeit not perfect) forcing function to make sure we keep prod up to date with staging

lmk what you think. curious for @bartek and @will 's thoughts too

I think this process makes sense to me. There were a few times where we ran into problems because production didn't reflect staging, so this would make the state of both explicit.

I wasn't following this convention in my services (on which I was working mostly alone), except for Identity where you introduced it. @varun's reasoning makes sense to me, so if it's helpful for you, I'm not opposed to keeping it. Especially since now there are three of us working on Identity so it's good to keep things clear

setting @ashoat as blocking