The interruptible: true keyword marks a job as safe to cancel when a newer pipeline starts for the same ref. It has no effect on its own. The project setting for auto-cancelling redundant pipelines must also be on, and it is enabled by default for new projects but frequently off on older ones.
The cancellation rule has a further subtlety: a pipeline is only cancelled if every job that has already started is interruptible. One long-running job without the flag, typically a deploy, blocks cancellation of the entire pipeline including the interruptible jobs beside it. That is deliberate, since cancelling a half-finished deploy is worse than wasting runner time.
Set interruptible: true as a default under the top-level default: key and override it to false on deploy jobs only. Verify the behavior by pushing twice in quick succession and checking whether the first pipeline moves to canceled. GitLab 16.x and later also expose auto-cancel behavior per pipeline through workflow: auto_cancel:, which allows cancelling on new commits without waiting for the whole-pipeline condition.