Can anyone help me please as that branch is gone, I have Jenkins 2.73.3 
installed but how do I use this feature as it says available from 2.30?  

I've spent much longer on trying to get this to work than I thought I 
would, for reference I've been over these before finally finding this forum 
post: 

http://johndstein-blog.logdown.com/posts/428667
https://github.com/membrane/jenkins-git-tag-builder
'albertskis' answer: 
https://stackoverflow.com/questions/29742847/jenkins-trigger-build-if-new-tag-is-released
https://github.com/jenkinsci/github-branch-source-plugin/pull/158/
https://issues.jenkins-ci.org/browse/JENKINS-34395

thanks
Wayne
On Wednesday, November 1, 2017 at 4:40:39 PM UTC, 
[email protected] wrote:
>
> hmm, I checked out your branch:
> https://github.com/stephenc/github-branch-source-plugin/tree/jenkins-34395
> compiled and installed: 2.2.5-SNAPSHOT (private-e98acfa4-root)
> but still not seeing any tags built
>
>
>
> On Wednesday, 1 November 2017 16:54:22 UTC+1, Stephen Connolly wrote:
>>
>> 2.2.4 does not have discovery of tags merged yet
>>
>> On 1 November 2017 at 08:15, <[email protected]> wrote:
>>
>>> I've got version 2.2.4 of GitHub Branch Source Plugin installed, and
>>> compiled, installed, and configured my organization folder to use 
>>> https://github.com/AngryBytes/jenkins-build-everything-strategy-plugin
>>> which uses:
>>>      @Override
>>>     public boolean isAutomaticBuild(SCMSource source, SCMHead head) {
>>>         return true;
>>>     }
>>>
>>> then I run a Scan the organization folder, but don't see any mention to 
>>> the tags. What's up with that? Is there something else missing along the 
>>> way?
>>>
>>> Examining org/repo
>>>
>>>   Checking branches...
>>>
>>>   Getting remote branches...
>>>
>>>     Checking branch feature/publishers
>>>       ‘Jenkinsfile’ found
>>>     Met criteria
>>> No changes detected: feature/publishers (still at 
>>> a29373c2e692bf549f7ff114e4be6ed82f7d056d)
>>>
>>>     Checking branch master
>>>       ‘Jenkinsfile’ found
>>>     Met criteria
>>> No changes detected: master (still at 
>>> a9bc55ee5d6e82111f6ca70ea6168da9289ddd12)
>>>
>>>     Checking branch test
>>>       ‘Jenkinsfile’ found
>>>     Met criteria
>>> No changes detected: test (still at 
>>> b224b0276df138020efed0d1545f97c4bff294cd)
>>>
>>>   3 branches were processed
>>>
>>>   Checking pull-requests...
>>>
>>>   Getting remote pull requests...
>>>
>>>   0 pull requests were processed
>>>
>>> Finished examining org/repo
>>>
>>>
>>>
>>>
>>> On Thursday, 7 September 2017 11:43:41 UTC+2, Stephen Connolly wrote:
>>>>
>>>>
>>>>
>>>> On 6 September 2017 at 23:24, Stephen Connolly <[email protected]
>>>> > wrote:
>>>>
>>>>>
>>>>> On Thu 7 Sep 2017 at 07:22, Stephen Connolly <[email protected]> 
>>>>> wrote:
>>>>>
>>>>>> You are waiting on 
>>>>>> https://github.com/jenkinsci/github-branch-source-plugin/pull/158 to 
>>>>>> be merged then.
>>>>>>
>>>>>> You could build the plugin with the PR merged and do some testing to 
>>>>>> help give better confidence for releasing that PR
>>>>>>
>>>>>>
>>>>>> On Thu 7 Sep 2017 at 00:43, <[email protected]> wrote:
>>>>>>
>>>>>>> Oh, to clarify, we're using the "github branch source" plugin and I 
>>>>>>> have already confirmed that github is correctly firing the webhook.
>>>>>>>
>>>>>>
>>>>> Hmmm the event side of that PR may need updating... 
>>>>>
>>>>> Would be really good to see if tags get created by events or if they 
>>>>> only show on an index with the current PR
>>>>>
>>>>
>>>> Had a look at the code, tag events were not being handled, so I pushed 
>>>> https://github.com/jenkinsci/github-branch-source-plugin/pull/158/commits/51fc6efbfed92f541032ed672be2ee9d9ac2e398
>>>>  
>>>> which should provide event support for tags
>>>>
>>>> Now if you want tags to build automatically, then you will need to 
>>>> write an extension plugin for branch-api that provides an implementation 
>>>> of 
>>>> https://github.com/jenkinsci/branch-api-plugin/blob/master/src/main/java/jenkins/branch/BranchBuildStrategy.java
>>>>  
>>>> (one there is at least one BranchBuildStrategy extension defined in your 
>>>> Jenkins then the BranchSource should allow you to add the strategies: 
>>>> https://github.com/jenkinsci/branch-api-plugin/blob/master/src/main/resources/jenkins/branch/BranchSource/config.jelly#L45
>>>>  
>>>> Note though, 
>>>> https://github.com/jenkinsci/branch-api-plugin/blob/22c8d12a5ad3b523042343bb769b15affb11d1a6/src/main/java/jenkins/branch/MultiBranchProject.java#L2162-L2173
>>>>  
>>>> so if you configure a source with one or more BranchBuildStrategy 
>>>> instances 
>>>> then that source will stop using the default behaviour of auto-build 
>>>> anything that is not a tag, so you might need more than one strategy to 
>>>> provide the flexibility you want
>>>>  
>>>>
>>>>>
>>>>>
>>>>>>>
>>>>>>> On Wednesday, September 6, 2017 at 4:38:05 PM UTC-7, 
>>>>>>> [email protected] 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 [email protected].
>>>>>>> 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.
>>>>>>>
>>>>>> -- 
>>>>>> Sent from my phone
>>>>>>
>>>>> -- 
>>>>> Sent from my phone
>>>>>
>>>>
>>>> -- 
>>> 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/d90508e3-95e4-42a9-99be-70d75ae54da0%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/jenkinsci-users/d90508e3-95e4-42a9-99be-70d75ae54da0%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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/cd55f068-bc62-427b-bf11-f5db1fa3e706%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to