The current git plugin does not provide a convenient way to build something that has been tagged if it has already been built. If you're willing to be on the cutting edge, you could install a pull request build <https://ci.jenkins.io/blue/organizations/jenkins/Plugins%2Fgit-plugin/detail/PR-528/1/artifacts> of Stephen Connolly's work to add richer support for tags.
There are ways to force a build of something that has already been built (for example, parameterize a build with the SHA1 to be built and the tag to be applied). I think that is close to what you're seeking, since your multi-branch pipeline evaluates every change, but you want to make a later decision if that build should be promoted. I'm not sure that is entirely what you're seeking, but it is closer to what you're seeking. Mark Waite On Wed, Sep 6, 2017 at 5:43 PM <ahamm...@anchorfree.com> wrote: > Oh, to clarify, we're using the "github branch source" plugin and I have > already confirmed that github is correctly firing the webhook. > > > On Wednesday, September 6, 2017 at 4:38:05 PM UTC-7, > aham...@anchorfree.com wrote: >> >> 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 jenkinsci-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-users/2add8404-567b-400d-baa2-2562cebe867f%40googlegroups.com > <https://groups.google.com/d/msgid/jenkinsci-users/2add8404-567b-400d-baa2-2562cebe867f%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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 jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtHVrYxoLktg7g4LYotf09WTQin_V_eVq5UMi84CN9Fk7A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
