To the ones using GitLab CI/CD:

Is there a way to trigger a pipeline run on a specific commit? Like in a situation where you're deploying every commit to master into prod, and you need to roll back, but without reverting the commit history.

Why not rerun an old pioeline?

@alexbrooklyn To keep a better history of what has happened in the project. It's not a huge thing, but would really be nice to have

Create a new local branch, hard reset it to the commit in question, push it upstream and trigger the pipeline.

Alternately, do the same thing, but with tags.

@rutee07 I'm not sure we're talking about the same thing? This isn't something to be run every time, but only if something goes wrong with the deployment

@SortOfTested That's exactly the kind of thing I want to avoid

@KasperNS
That's exactly the only kind of thing they support ,🤷‍♀️

@KasperNS if it's about history, just re-running the pipeline would be perfect?
IIRC it should show up at the very top, as the latest pipeline, as a new one.

Do you want to remove one commit while keeping all else?

One way is to do a revert, this will be a new commit that is the reverse of the original, just as if you manually returned everything and commited.

If it is the last commit its usually trivial and you will have the commit and the revert so you have full history if that the commit did happen.

What @Voxera said.

@theKarlisK Thank you! That's exactly what I wanted

@Voxera & @magicMirror, thanks for the answers, but I stated in the original post that I did not want to rely on reverting the commit history

@KasperNS Sure.

This means the 1-1 master-production relationship will not hold in your scenario.

@magicMirror true, but that doesn't matter in this case. This scenario is for the rare "oh fuck" moments, where a bug's gone into production, and the next commit is going to be something that should fix it.

Then you can agree or disagree whether you think that's a good strategy. Personally I think it's better than reverting, when you step back and look at it from a full DevOps perspective, and not just git

@KasperNS In case the deploys are really fast, and a fix is coming soon - then no problem.
But If the fix will take a long time, and other stuff needs to be deployed between deploy/issue/rollback and deploy/fixed...
It depends on your scenario.

@magicMirror yeah I agree with that. We're very agile where I work, and a fix is usually in place within a few hours