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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev /max http://about.me/maxandersen _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

in other words, start with a :) > a) does the PR break my tests / want a green light on the PR page

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.)

On Tue, Apr 26, 2016 at 11:50 AM, Max Rydahl Andersen <manderse(a)redhat.com&gt; 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > > /max > http://about.me/maxandersen > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev(a)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

+100 to start with a) On 04/26/2016 02:20 PM, Nick Boldt wrote: > https://issues.jboss.org/browse/JBIDE-21657 > > On Tue, Apr 26, 2016 at 1:13 PM, Mickael Istria <mistria(a)redhat.com&gt; wrote: >> On 04/26/2016 05:50 PM, Max Rydahl Andersen wrote: >> >> in other words, start with a :) >> >>> a) does the PR break my tests / want a green light on the PR page >> +1000. Is there a Jira for that? >> -- >> Mickael Istria >> Eclipse developer at JBoss, by Red Hat >> My blog - My Tweets >> >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev > > _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

Just trying to build PR for is good, +1000. That would let us to know what kind of problems we should solve to make it happen. Then we can figure out manual process for pushing PRs and do it one by one starting from root of dependency tree. Could you also look what info we can pull out of PR, like description text, comment or anything else? Thanks Denis On Wed, Apr 27, 2016, 08:01 Nick Boldt <nboldt(a)redhat.com&gt; wrote: > > One PR in Base will not automatically cause the results of that PR to > be picked up by downstream projects (eg., Server, Openshift) or > JBT/JBDS aggregation -- to do that would require passing in a > commandline override for > > -Djbosstools-base-site=http://path/to/output/of/the/pull-request/build/repo/ > ... for all the downstream projects of Base, and ensuring that the > output was published to a /pulls/ folder instead of the usual /builds/ > folder. > > So if I'm going down this road I wanted to make sure we think a little > about how the future might unfold, and how we might get there. Rather > not be painted into a corner. :D > > On Tue, Apr 26, 2016 at 6:59 PM, Alexey Kazakov <alkazako(a)redhat.com&gt; > wrote: > > +100 to start with a) > > > > On 04/26/2016 02:20 PM, Nick Boldt wrote: > >> https://issues.jboss.org/browse/JBIDE-21657 > >> > >> On Tue, Apr 26, 2016 at 1:13 PM, Mickael Istria <mistria(a)redhat.com&gt; > >> wrote: > >>> On 04/26/2016 05:50 PM, Max Rydahl Andersen wrote: > >>> > >>> in other words, start with a :) > >>> > >>>> a) does the PR break my tests / want a green light on the PR page > >>> +1000. Is there a Jira for that? > >>> -- > >>> Mickael Istria > >>> Eclipse developer at JBoss, by Red Hat > >>> My blog - My Tweets > >>> > >>> _______________________________________________ > >>> jbosstools-dev mailing list > >>> jbosstools-dev(a)lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev > >> > >> > > > > _______________________________________________ > > jbosstools-dev mailing list > > jbosstools-dev(a)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 > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev

I think it is beyond overkill to even try for b). wildfly doesn't rebuild and run the test suite for a given change in jasper, for example. The entire idea that not even an actual change, but a potential change / PR, to base, could end up kicking off the entire product build and their associated test suites. I think this is beyond overkill: it's dangerous and will sap computing power and lock up slaves doing what's essentially no-ops.

PR's change frequently. Imagine a change in base that gets a few different revisions? Suddenly I can't even update my PR to change some text string without it kicking off a potential entire build chain and test suite.

Not to mention, what if the upstream tests were already failing?

You'd have to build all the upstream plugins with the OLD base, then build base, build everything, run all the tests, and somehow compare the new test results to the previous test results.

I think this is folly, and it should not be pursued at all. Start with a), and finish with a).

> > On Tue, Apr 26, 2016 at 6:59 PM, Alexey Kazakov <alkazako(a)redhat.com&gt; > wrote: >> +100 to start with a) >> >> On 04/26/2016 02:20 PM, Nick Boldt wrote: >>> https://issues.jboss.org/browse/JBIDE-21657 >>> >>> On Tue, Apr 26, 2016 at 1:13 PM, Mickael Istria >>> <mistria(a)redhat.com&gt; wrote: >>>> On 04/26/2016 05:50 PM, Max Rydahl Andersen wrote: >>>> >>>> in other words, start with a >>>> >>>>> a) does the PR break my tests / want a green light on the PR page >>>> +1000. Is there a Jira for that? >>>> -- >>>> Mickael Istria >>>> Eclipse developer at JBoss, by Red Hat >>>> My blog - My Tweets >>>> >>>> _______________________________________________ >>>> jbosstools-dev mailing list >>>> jbosstools-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>> >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev > >

_______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

Is there a Jira existing on this topic?

-- Mickael Istria Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools> My blog <http://mickaelistria.wordpress.com> - My Tweets <http://twitter.com/mickaelistria>

_______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev