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]
> <javascript:>> wrote:
>
>>
>> On Thu 7 Sep 2017 at 07:22, Stephen Connolly <[email protected]
>> <javascript:>> 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] <javascript:>>
>>> 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] <javascript:>.
>>>> 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.
For more options, visit https://groups.google.com/d/optout.
