One of the fundamental concepts in CI/CD is "build once". So... we build for every commit and test. Code which we want to promote, we merge and then test again. If tests pass, we tag it with a release number in git (v3.2 for example) and push that. I expect jenkins to fire a build. Our jenkinsfile will then do a docker pull and discover it's already built, apply the new tag and docker push.
But it sounds like this workflow is fundamentally not possible with Jenkins. Is that correct? A On Friday, July 14, 2017 at 9:00:10 AM UTC-7, Mark Waite wrote: > > > > On Friday, July 14, 2017 at 7:56:00 AM UTC-8, Samuel Henrique wrote: >> >> Hello, >> >> I'm trying to make jenkins trigger a build whenever a new tag is pushed >> to my git repo. >> >> I already made it to trigger builds when a tag pointing to a new commit >> is pushed, by setting: >> >> *refspec:* +refs/tags/*:refs/remotes/origin/tags/* >>> *branch specifier:* ** >> >> >> The problem is that the builds are not triggered when i tag some commit >> that already has another tag, even if its an annotated tag. >> >> The use case is as follows: >> >> 1)We need devs to be able to deploy our webapp by tagging releases on >> github (mostly in other branches than master), like tag: v1.0.0 (the >> previous tag was v0.9.9). >> 2)We need to be able to rollback deploys, by tagging again previous >> releases (rollbacks will be always tagging commits on master), like tag: >> v0.9.9-rollback [ponting to the same commit as v0.9.9). >> 3)We also need to follow some process that would allow fresh servers to >> retrieve the same deployed release as the other servers (dealing with >> autoscalling/dynamic inventory) >> >> The 3rd item is easily solvable by configuring capistrano to self-deploy >> the last tag (sorting tags by taggerdate) on server startup (so new >> machines will fetch rollbacks too). >> >> The 1st item is already good, as jenkins always trigger a build when a >> tag ponting to a new commit is pushed. >> >> My problem is with rollbacks (2nd item), jenkins will receive the git >> hook, poll the repository but won't trigger the build, it detects the new >> tag but it acts as it already built that. >> >> I've searched online and from what i read, i think the git plugin is >> checking the hash the tag points to, not the hash from the tag itself, thus >> it doesn't detect a change. Can somebody confirm if i'm right, or if the >> problem is is another plugin? >> >> > That is correct. The git plugin assumes that once it has built a commit, > then it does not need to build it again. > > There are alternatives that may allow you to force a build of an already > built commit. For instance, you could parameterize a build to take the tag > of the commit to build as an argument, then invoke it with a POST from the > "curl" command to build that specific tag. That isn't as elegant as the > webhook technique that you're trying to use, since it requires that you > create something that detects the creation of a new tag, then when the new > tag is detected, it calls that curl command. > > Mark Waite > > >> Any help is highly appreciated. >> > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/3438e084-53c4-467e-9cdb-7c84acae60de%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
