I am trying to better understand some undesirable behaviour on a cancelled GH workflow that handles deploying to fly (with flyctl deploy) – in the event of a deploy (workflow) being cancelled before completing, our DB still gets the latest migrations, this leads me to believe that the release_command: 'npx prisma migrate deploy' might not be running when I expect it to.
Can anyone clarify? 
Hi… This happens after a new image is built from the Dockerfile but before any existing Machines are updated to use it. To know this, a person needs to piece together two different parts of the the official docs:
To run a command in a temporary Machine—using the app’s successfully built Docker image—before the release is deployed, define a
release_command:
This is useful for running database migrations before app Machines are created or updated with the new release.
And you can see it more directly in a (duly) helpful comment in the source code:
// deployMachinesApp executes the following flow:
// - Run release command
// - Remove spare machines from removed groups
// - Launch new machines on new groups
// - Update existing machines
If you have a lot of Machines and were canceling in the middle of the rolling update of them, then you were already way down in that 4th step, 
.
Hope this helps!
Thanks for clarifying! I had misunderstood the phrase ‘before the release is deployed’ to mean ‘after all machines have been provisioned’."
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.