5:28 p.m.
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
5:50 p.m.
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
6:37 p.m.
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> 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
10:12 p.m.
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(a)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(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
/max
http://about.me/maxandersen
6:43 p.m.
starting with a) would be great, indeed.
/Xavier
On 26 Apr 2016, at 17:50, Max Rydahl Andersen
<manderse(a)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(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
7:13 p.m.
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 <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
8:20 p.m.
https://issues.jboss.org/browse/JBIDE-21657
On Tue, Apr 26, 2016 at 1:13 PM, Mickael Istria <mistria(a)redhat.com> 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
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
12:59 a.m.
+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> 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
5:01 p.m.
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> 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> 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
9:51 p.m.
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> 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>
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>
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
11:22 p.m.
"The plugin makes some very useful environment variables available.
ghprbActualCommit
ghprbActualCommitAuthor
ghprbActualCommitAuthorEmail
ghprbPullDescription
ghprbPullId
ghprbPullLink
ghprbPullTitle
ghprbSourceBranch
ghprbTargetBranch
sha1" --
https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+p...
On Thu, Apr 28, 2016 at 3:51 PM, Denis Golovin <dgolovin(a)gmail.com> wrote:
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> 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>
> 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>
> >> 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
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
6:47 a.m.
On 04/27/2016 11:01 AM, Nick Boldt 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
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>
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>
>> 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
2:55 p.m.
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.
not true - if done right you don't need to rebuild everything you just
run the test suite again.
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.
No, it would be kicking of a build chain once you decided you PR gets
merged into master of your component.
This "B" would not run as often as your "A.
Not to mention, what if the upstream tests were already failing?
If they did they should be rolled back to not fail. That is the very
critical difference in approach to what you actually commit into your
master.
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.
No, you would not need to build everything - you would run the tests
firsts. Then if need be recompile if broken binary compatibility and
then yes compare results - this is not new. I did this for systems I
built 10 years ago - albeit it was not an Eclipse desktop UI.
I think this is folly, and it should not be pursued at all.
Start with a), and finish with a).
Start with A, lets see where that brings us.
Some kind of B is definitely a requirement if we want to scale to know
within hours rather than months if we can release.
/max
>
> On Tue, Apr 26, 2016 at 6:59 PM, Alexey Kazakov <alkazako(a)redhat.com>
> 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> 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
/max
http://about.me/maxandersen
11:29 p.m.
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>
8:40 a.m.
On 8 May 2016, at 23:29, Mickael Istria wrote:
Is there a Jira existing on this topic?
https://issues.jboss.org/browse/JBIDE-21657
--
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
/max
http://about.me/maxandersen
2909
days inactive
2922
days old
jbosstools-dev@lists.jboss.org
14 comments
8 participants
participants (8)
-
Alexey Kazakov -
André Dietisheim -
Denis Golovin -
Max Rydahl Andersen -
Mickael Istria -
Nick Boldt -
Rob Stryker -
Xavier Coulon