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, <j.kn...@travelaudience.com <javascript:>> > 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 <stephen.al...@gmail.com> >>> wrote: >>> >>>> >>>> On Thu 7 Sep 2017 at 07:22, Stephen Connolly <stephen.al...@gmail.com> >>>> 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, <aham...@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. >>>>>> >>>>> >>>> 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, >>>>>> 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-use...@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. >>>>>> >>>>> -- >>>>> 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 jenkinsci-use...@googlegroups.com <javascript:>. >> 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 jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/9c013866-d7e8-4d64-b55b-82359613a995%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
