| >> 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. |