[jbosstools-dev] Can we have a jenkins build triggered upon github PR?

[Max Rydahl Andersen]

On 26 Apr 2016, at 18:37, Nick Boldt wrote:

> b) means "a PR change in Base could be used to rebuild Server, to
> verify no tests now fail"
>
> c) means "simply aggregate the PR change in Base + all the latest
> Server, Openshift, etc. bits from master" to be able to push that PR
> change into a DP installer CI build
>
> So they solve two different needs and will catch different problems.
>
> But I'm not sure how to report back the status of any
> downstream-PR-caused builds back to the original PR. Also not sure how
> to contain situations where there's a pair (or trio?) of tied PRs
> ,
> eg., an API change in Base (PR#1) and the related change in Server
> (PR#2) & Openshift (PR#3). Either that's 3 builds, or it's 6 builds,
> or 8 builds ... ? (Been too long since my last combinatorics course.)

so I don't follow what your problem is here since *one* PR would be the 
trigger for all this so thats the one that would get the 'status' 
reported  - but I think we are jumping way ahead of what needs done 
first, so lets start with one PR doing a build and report if that fails 
the build for that repo.

/max

>
>
> On Tue, Apr 26, 2016 at 11:50 AM, Max Rydahl Andersen
> <manderse at redhat.com> wrote:
>> a first.
>>
>> b is a separate thing and much more complex IMO
>>
>> c how is that different from b ?
>>
>> in other words, start with a :)
>>
>> /max
>>> Hi
>>>
>>> I'd love to get a build triggered when I create a PR in github. That
>>> would allow me to force awareness of breaking tests with a change.
>>> When talking to Nick he was pointing out that there are actually 3 
>>> items
>>> that he's after currently, where my suggestion is the 1st of these 
>>> aims.
>>>
>>> a) does the PR break my tests / want a green light on the PR page
>>> b) does the PR break downstream (eg., API change in Base breaks 
>>> Server
>>> or UI change in Server breaks Openshift)
>>> c) does the PR need to be aggregated into JBT or JBDS so we can see 
>>> it
>>> in the larger context
>>>
>>> a) is what I'd love to get and is good enough for me now.
>>> b) is imho a nice-to-have but wasnt that much of a problem in 
>>> OpenShift
>>> lately.
>>> c) I guess is the larger picture where we want to achieve continous
>>> delivery.
>>>
>>> Nick wants to know about the need of other component leads. So 
>>> please
>>> speak up. a), b), c), all of them, etc?
>>>
>>> Cheers
>>> Andre
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>> jbosstools-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>>
>> /max
>> http://about.me/maxandersen
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
>
>
> -- 
> Nick Boldt :: JBoss by Red Hat
> Productization Lead :: JBoss Tools & Dev Studio
> http://nick.divbyzero.com


/max
http://about.me/maxandersen