This message was deleted.
# general
s
This message was deleted.
👍 6
m
We would also be interested to understand this.
t
As of now, our solution is to replay the previous job. This makes sense but, maybe together we can discuss a more elegant solution.
g
I always considered replaying the previous job the best option for a rollback. In case of a failure what I want is for my service(s) to be exactly as they were on the last successful deploy. Since doing the deploy requires credentials it has to be done in the exact same environment as before, which might also have changed (might even be the cause of the failure), so rolling back from a job on the same commit may break things even more. What I usually do is a job to be executed when the deploy fails, it runs a script to list the pipelines of the project and create a new one on the same commit of the last successful one. Currently I'm running on Github Actions and doing the same thing.
👍 1
❤️ 1
t
Just updating this thread with another solution
Guys this is what I did to handle rollback, I first create an output object called
Copy code
export const appTag ='your image tag';
before I run pulumi update, I query the output file like this
Copy code
export PREV_APP_TAG=$(pulumi stack output -j | jq '.appTag')
And then if my update fails, i set this
Copy code
pulumi config set app:tag $PREV_APP_TAG
and then run a pulumi update again.
👍 1