[mugsie]

> Jenkins has some serious problems when you want to work with CD.

When you want to work with CD in a particular way.

A simple fix to the above issue would be to have a "production" branch. When you want to do a release, you merge to the production branch. A roll back would just be a revert of the commits since the last merge to production, and could even be tagged.

If you are doing CD by allowing devs to tag random branches, cool, but I would not call it a "failure" on the Jenkins side.

> Unfortunately, hack such a fix is not very pleasant either, because Java, and i don't think the Jenkins developers are interested in it either, at least not if just a few people ask for it.

Its a webhook - that can be in any language, or if you use Git(hub|lab) a config item.

[samueloph]

>> Jenkins has some serious problems when you want to work with CD.

> When you want to work with CD in a particular way.

> A simple fix to the above issue would be to have a "production" branch. When you want to do a release, you merge to the production branch. A roll back would just be a revert of the commits since the last merge to production, and could even be tagged.

> If you are doing CD by allowing devs to tag random branches, cool, but I would not call it a "failure" on the Jenkins side.

Well, i must confess i agree with you and my first idea was this, i will probably end up pushing for that anyway, but i will have to convince some devs that they should not be afraid of git reverts. When i first mentioned the idea, some devs with deploy rights said they were skeptical about this because they were afraid of having a git revert shitstorm in a SOS situation.

>> Unfortunately, hack such a fix is not very pleasant either, because Java, and i don't think the Jenkins developers are interested in it either, at least not if just a few people ask for it.

> Its a webhook - that can be in any language, or if you use Git(hub|lab) a config item.

Not exactly, on this case github only lets me create webhooks with 'create' action, which is trigerred "Any time a Branch or Tag is created.", so new branches would trigger deploys.

[falsedan]

> When you want to work with CD in a particular way.

I think that I, as the user of the project, should get to decide how I want to deploy my software. So, yes, I do want to CD things in a particular way: one that matches my developer's expectations and my business requirements.

> CD

Jenkins isn't a deployment tool. It can act like one, but this (rollback) is a classic example of how it's a build, not release, tool.

To address OP's complaint: we rebuild steps from the previous pipeline to perform a rollback, and we have all our deployment logic in a separate system which works with commit IDs, if the previous pipeline has been pushed out of the list of recent pipeline runs.

[mugsie]

> I think that I, as the user of the project, should get to decide how I want to deploy my software. So, yes, I do want to CD things in a particular way: one that matches my developer's expectations and my business requirements.

Sure - it definitely is. But we all have to do that within the limitations of the tools we use. Jenkins makes an assumption (in the default mode) of a continuously moving HEAD - which may or may not be what you want. It doesn't make Jenkins bad - it makes it not suitable for your use case.

FWIW - adapting to using a moving HEAD is not that hard - `git reset <old-tag> && git commit -a -m "Revert deploy <failed-tag> && git tag <failed-tag+1> && git push` - but I totally understand why people would not like to use that style. It is a personal / culture choice.