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] <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 <[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] <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 [email protected]. 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.
