You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by Edward Ribeiro <ed...@gmail.com> on 2016/10/27 15:54:17 UTC
QA github pre-commit queue
Dear community,
As part of the github move, we are still lacking the plumbing that allows
to run Jenkins CI tests, etc, on open Pull Requests. Please, take a look at
Kafka pending PR at Github to see what I am referring to.
Any committer could open an INFRA JIRA to address this?
Best regards,
Eddie
Re: [DISCUSS] QA github pre-commit queue
Posted by Flavio P JUNQUEIRA <fp...@apache.org>.
My bad, I made the build parameterized to see if I could trigger it
manually. I have disabled the parameters and should be back to normal now.
-Flavio
On Tue, Nov 8, 2016 at 4:00 PM, Michael Han <ha...@cloudera.com> wrote:
> Git PR bot builds
> <https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/> have
> been failing after build 44. From the log it looks like for some reasons,
> variables like 'GIT_PR_NUMBER', 'GIT_PR_TITLE' etc were undefined. Is this
> a configuration issue of build bot?
>
> On Mon, Nov 7, 2016 at 9:49 AM, Michael Han <ha...@cloudera.com> wrote:
>
> > +1 for disabling jira qa and only support pull request for code change
> > contributions. Besides making support easier this approach is also
> aligned
> > with what Spark and Kafka is doing, and being consistent across Apache
> > projects regarding how to use PR seems a good thing to do.
> >
> > >> have the tool upload the *.patch file to Jira for archiving purposes.
> > I think nothing will prevent a user submit a patch file to JIRA with our
> > script changes, so the functionality of archiving patches will still
> work.
> > Though, I noticed that Kafka [1] and Spark [2] explicitly stated that do
> > not include patch file in JIRA for code contributions, so probably we'd
> do
> > this too for consistency purpose? Are there any benefit of archiving
> > patches given we prefer (or actually require) pull request instead of
> > patches?
> >
> > [1] https://cwiki.apache.org/confluence/display/KAFKA/
> > Contributing+Code+Changes#ContributingCodeChanges-PullRequest
> > [2] https://cwiki.apache.org/confluence/display/SPARK/
> > Contributing+to+Spark#ContributingtoSpark-PullRequest
> >
> > On Mon, Nov 7, 2016 at 8:04 AM, Edward Ribeiro <edward.ribeiro@gmail.com
> >
> > wrote:
> >
> >> I am +1 about having patches submitted via PRs. IMHO, we should disable
> >> the
> >> Jira QA altogether, but have the tool upload the *.patch file to Jira
> for
> >> archiving purposes.
> >>
> >> On Sun, Nov 6, 2016 at 6:42 PM, Raúl Gutiérrez Segalés <
> >> rgs@itevenworks.net>
> >> wrote:
> >>
> >> > On 6 November 2016 at 11:54, Flavio Junqueira <fp...@apache.org> wrote:
> >> >
> >> > > ZOOKEEPER-2624 has been merged, thank Raul, Ben and Michael for
> >> > reviewing.
> >> > >
> >> > > The QA for pull requests should be working for pull requests agains
> >> > > master, but let's keep an eye and polish any rough edges that might
> >> still
> >> > > be there.
> >> > >
> >> > > With ZOOKEEPER-2624 in, there is one last major decision we need to
> >> make
> >> > > to wrap this up. The pull request QA currently do not make a jira
> >> patch
> >> > > available. This is intentional because making it patch available
> will
> >> > > trigger the original Jira QA, which will be confusing because we
> will
> >> > see a
> >> > > failure (I haven't tested, but I think that's what's going to
> >> happen). If
> >> > > we change the script to make the Jira patch available, then we need
> to
> >> > > either:
> >> > >
> >> > > 1- Disable the Jira QA altogether, which means that we will only
> have
> >> > pull
> >> > > request QA available
> >> > > 2- Make the Jira QA script spot that there is a pull request
> available
> >> > and
> >> > > not build it.
> >> > >
> >> > > I'm wondering if folks would be ok with only having patches
> submitted
> >> via
> >> > > pull requests or if we should continue to support the old Jira QA.
> >> > >
> >> >
> >> > I am +1 on only having patches submitted via PRs, it's simpler to only
> >> have
> >> > to support one method. Thanks Flavio for making this happen!
> >> >
> >> >
> >> > -rgs
> >> >
> >>
> >
> >
> >
> > --
> > Cheers
> > Michael.
> >
>
>
>
> --
> Cheers
> Michael.
>
Re: [DISCUSS] QA github pre-commit queue
Posted by Michael Han <ha...@cloudera.com>.
Git PR bot builds
<https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/> have
been failing after build 44. From the log it looks like for some reasons,
variables like 'GIT_PR_NUMBER', 'GIT_PR_TITLE' etc were undefined. Is this
a configuration issue of build bot?
On Mon, Nov 7, 2016 at 9:49 AM, Michael Han <ha...@cloudera.com> wrote:
> +1 for disabling jira qa and only support pull request for code change
> contributions. Besides making support easier this approach is also aligned
> with what Spark and Kafka is doing, and being consistent across Apache
> projects regarding how to use PR seems a good thing to do.
>
> >> have the tool upload the *.patch file to Jira for archiving purposes.
> I think nothing will prevent a user submit a patch file to JIRA with our
> script changes, so the functionality of archiving patches will still work.
> Though, I noticed that Kafka [1] and Spark [2] explicitly stated that do
> not include patch file in JIRA for code contributions, so probably we'd do
> this too for consistency purpose? Are there any benefit of archiving
> patches given we prefer (or actually require) pull request instead of
> patches?
>
> [1] https://cwiki.apache.org/confluence/display/KAFKA/
> Contributing+Code+Changes#ContributingCodeChanges-PullRequest
> [2] https://cwiki.apache.org/confluence/display/SPARK/
> Contributing+to+Spark#ContributingtoSpark-PullRequest
>
> On Mon, Nov 7, 2016 at 8:04 AM, Edward Ribeiro <ed...@gmail.com>
> wrote:
>
>> I am +1 about having patches submitted via PRs. IMHO, we should disable
>> the
>> Jira QA altogether, but have the tool upload the *.patch file to Jira for
>> archiving purposes.
>>
>> On Sun, Nov 6, 2016 at 6:42 PM, Raúl Gutiérrez Segalés <
>> rgs@itevenworks.net>
>> wrote:
>>
>> > On 6 November 2016 at 11:54, Flavio Junqueira <fp...@apache.org> wrote:
>> >
>> > > ZOOKEEPER-2624 has been merged, thank Raul, Ben and Michael for
>> > reviewing.
>> > >
>> > > The QA for pull requests should be working for pull requests agains
>> > > master, but let's keep an eye and polish any rough edges that might
>> still
>> > > be there.
>> > >
>> > > With ZOOKEEPER-2624 in, there is one last major decision we need to
>> make
>> > > to wrap this up. The pull request QA currently do not make a jira
>> patch
>> > > available. This is intentional because making it patch available will
>> > > trigger the original Jira QA, which will be confusing because we will
>> > see a
>> > > failure (I haven't tested, but I think that's what's going to
>> happen). If
>> > > we change the script to make the Jira patch available, then we need to
>> > > either:
>> > >
>> > > 1- Disable the Jira QA altogether, which means that we will only have
>> > pull
>> > > request QA available
>> > > 2- Make the Jira QA script spot that there is a pull request available
>> > and
>> > > not build it.
>> > >
>> > > I'm wondering if folks would be ok with only having patches submitted
>> via
>> > > pull requests or if we should continue to support the old Jira QA.
>> > >
>> >
>> > I am +1 on only having patches submitted via PRs, it's simpler to only
>> have
>> > to support one method. Thanks Flavio for making this happen!
>> >
>> >
>> > -rgs
>> >
>>
>
>
>
> --
> Cheers
> Michael.
>
--
Cheers
Michael.
Re: [DISCUSS] QA github pre-commit queue
Posted by Patrick Hunt <ph...@apache.org>.
On Wed, Nov 9, 2016 at 6:46 PM, Flavio Junqueira <fp...@apache.org> wrote:
>
> > On 09 Nov 2016, at 10:39, Patrick Hunt <ph...@apache.org> wrote:
> >
> > What are the implications of moving away from JIRA patches? Any legal/IP?
> > Also PRs are through github.com, which is not infra owned by Apache.
>
> This is supported by infra:
>
> https://reference.apache.org/pmc/github
>
> > If
> > that service ever goes away we'll lose that information.
>
> Comments on the pull request are currently propagated to the corresponding
> jira. See for example ZOOKEEPER-1525.
>
> > What are other
> > projects doing in this regard?
>
> I'm aware of at least 3 projects: Spark, Kafka, and BookKeeper.
>
> > Any impact on our workflows outside of
> > qabot? e.g. release other other activity tracking?
>
> Not that I'm aware of. The only difference if we make this change is that
> patch available would be set by our script and the script won't look for a
> patch in the jira.
>
>
Sounds reasonable - there are no downsides then?
Patrick
>
> >
> > Patrick
> >
> > On Tue, Nov 8, 2016 at 6:37 PM, Flavio P JUNQUEIRA <fp...@apache.org>
> wrote:
> >
> >> I don't have any strong argument for keeping the Jira patches other than
> >> the fact that this is what we have been doing since the project was
> >> created. If there is anyone who do not want to use github in the
> community,
> >> please speak up.
> >>
> >> -Flavio
> >>
> >> On Mon, Nov 7, 2016 at 9:49 AM, Michael Han <ha...@cloudera.com> wrote:
> >>
> >>> +1 for disabling jira qa and only support pull request for code change
> >>> contributions. Besides making support easier this approach is also
> >> aligned
> >>> with what Spark and Kafka is doing, and being consistent across Apache
> >>> projects regarding how to use PR seems a good thing to do.
> >>>
> >>>>> have the tool upload the *.patch file to Jira for archiving purposes.
> >>> I think nothing will prevent a user submit a patch file to JIRA with
> our
> >>> script changes, so the functionality of archiving patches will still
> >> work.
> >>> Though, I noticed that Kafka [1] and Spark [2] explicitly stated that
> do
> >>> not include patch file in JIRA for code contributions, so probably we'd
> >> do
> >>> this too for consistency purpose? Are there any benefit of archiving
> >>> patches given we prefer (or actually require) pull request instead of
> >>> patches?
> >>>
> >>> [1]
> >>> https://cwiki.apache.org/confluence/display/KAFKA/
> >>> Contributing+Code+Changes#ContributingCodeChanges-PullRequest
> >>> [2]
> >>> https://cwiki.apache.org/confluence/display/SPARK/
> Contributing+to+Spark#
> >>> ContributingtoSpark-PullRequest
> >>>
> >>> On Mon, Nov 7, 2016 at 8:04 AM, Edward Ribeiro <
> edward.ribeiro@gmail.com
> >>>
> >>> wrote:
> >>>
> >>>> I am +1 about having patches submitted via PRs. IMHO, we should
> disable
> >>> the
> >>>> Jira QA altogether, but have the tool upload the *.patch file to Jira
> >> for
> >>>> archiving purposes.
> >>>>
> >>>> On Sun, Nov 6, 2016 at 6:42 PM, Raúl Gutiérrez Segalés <
> >>>> rgs@itevenworks.net>
> >>>> wrote:
> >>>>
> >>>>> On 6 November 2016 at 11:54, Flavio Junqueira <fp...@apache.org>
> >> wrote:
> >>>>>
> >>>>>> ZOOKEEPER-2624 has been merged, thank Raul, Ben and Michael for
> >>>>> reviewing.
> >>>>>>
> >>>>>> The QA for pull requests should be working for pull requests agains
> >>>>>> master, but let's keep an eye and polish any rough edges that might
> >>>> still
> >>>>>> be there.
> >>>>>>
> >>>>>> With ZOOKEEPER-2624 in, there is one last major decision we need to
> >>>> make
> >>>>>> to wrap this up. The pull request QA currently do not make a jira
> >>> patch
> >>>>>> available. This is intentional because making it patch available
> >> will
> >>>>>> trigger the original Jira QA, which will be confusing because we
> >> will
> >>>>> see a
> >>>>>> failure (I haven't tested, but I think that's what's going to
> >>> happen).
> >>>> If
> >>>>>> we change the script to make the Jira patch available, then we need
> >>> to
> >>>>>> either:
> >>>>>>
> >>>>>> 1- Disable the Jira QA altogether, which means that we will only
> >> have
> >>>>> pull
> >>>>>> request QA available
> >>>>>> 2- Make the Jira QA script spot that there is a pull request
> >>> available
> >>>>> and
> >>>>>> not build it.
> >>>>>>
> >>>>>> I'm wondering if folks would be ok with only having patches
> >> submitted
> >>>> via
> >>>>>> pull requests or if we should continue to support the old Jira QA.
> >>>>>>
> >>>>>
> >>>>> I am +1 on only having patches submitted via PRs, it's simpler to
> >> only
> >>>> have
> >>>>> to support one method. Thanks Flavio for making this happen!
> >>>>>
> >>>>>
> >>>>> -rgs
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Cheers
> >>> Michael.
> >>>
> >>
>
>
Re: [DISCUSS] QA github pre-commit queue
Posted by Flavio Junqueira <fp...@apache.org>.
> On 09 Nov 2016, at 10:39, Patrick Hunt <ph...@apache.org> wrote:
>
> What are the implications of moving away from JIRA patches? Any legal/IP?
> Also PRs are through github.com, which is not infra owned by Apache.
This is supported by infra:
https://reference.apache.org/pmc/github
> If
> that service ever goes away we'll lose that information.
Comments on the pull request are currently propagated to the corresponding jira. See for example ZOOKEEPER-1525.
> What are other
> projects doing in this regard?
I'm aware of at least 3 projects: Spark, Kafka, and BookKeeper.
> Any impact on our workflows outside of
> qabot? e.g. release other other activity tracking?
Not that I'm aware of. The only difference if we make this change is that patch available would be set by our script and the script won't look for a patch in the jira.
-Flavio
>
> Patrick
>
> On Tue, Nov 8, 2016 at 6:37 PM, Flavio P JUNQUEIRA <fp...@apache.org> wrote:
>
>> I don't have any strong argument for keeping the Jira patches other than
>> the fact that this is what we have been doing since the project was
>> created. If there is anyone who do not want to use github in the community,
>> please speak up.
>>
>> -Flavio
>>
>> On Mon, Nov 7, 2016 at 9:49 AM, Michael Han <ha...@cloudera.com> wrote:
>>
>>> +1 for disabling jira qa and only support pull request for code change
>>> contributions. Besides making support easier this approach is also
>> aligned
>>> with what Spark and Kafka is doing, and being consistent across Apache
>>> projects regarding how to use PR seems a good thing to do.
>>>
>>>>> have the tool upload the *.patch file to Jira for archiving purposes.
>>> I think nothing will prevent a user submit a patch file to JIRA with our
>>> script changes, so the functionality of archiving patches will still
>> work.
>>> Though, I noticed that Kafka [1] and Spark [2] explicitly stated that do
>>> not include patch file in JIRA for code contributions, so probably we'd
>> do
>>> this too for consistency purpose? Are there any benefit of archiving
>>> patches given we prefer (or actually require) pull request instead of
>>> patches?
>>>
>>> [1]
>>> https://cwiki.apache.org/confluence/display/KAFKA/
>>> Contributing+Code+Changes#ContributingCodeChanges-PullRequest
>>> [2]
>>> https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark#
>>> ContributingtoSpark-PullRequest
>>>
>>> On Mon, Nov 7, 2016 at 8:04 AM, Edward Ribeiro <edward.ribeiro@gmail.com
>>>
>>> wrote:
>>>
>>>> I am +1 about having patches submitted via PRs. IMHO, we should disable
>>> the
>>>> Jira QA altogether, but have the tool upload the *.patch file to Jira
>> for
>>>> archiving purposes.
>>>>
>>>> On Sun, Nov 6, 2016 at 6:42 PM, Raúl Gutiérrez Segalés <
>>>> rgs@itevenworks.net>
>>>> wrote:
>>>>
>>>>> On 6 November 2016 at 11:54, Flavio Junqueira <fp...@apache.org>
>> wrote:
>>>>>
>>>>>> ZOOKEEPER-2624 has been merged, thank Raul, Ben and Michael for
>>>>> reviewing.
>>>>>>
>>>>>> The QA for pull requests should be working for pull requests agains
>>>>>> master, but let's keep an eye and polish any rough edges that might
>>>> still
>>>>>> be there.
>>>>>>
>>>>>> With ZOOKEEPER-2624 in, there is one last major decision we need to
>>>> make
>>>>>> to wrap this up. The pull request QA currently do not make a jira
>>> patch
>>>>>> available. This is intentional because making it patch available
>> will
>>>>>> trigger the original Jira QA, which will be confusing because we
>> will
>>>>> see a
>>>>>> failure (I haven't tested, but I think that's what's going to
>>> happen).
>>>> If
>>>>>> we change the script to make the Jira patch available, then we need
>>> to
>>>>>> either:
>>>>>>
>>>>>> 1- Disable the Jira QA altogether, which means that we will only
>> have
>>>>> pull
>>>>>> request QA available
>>>>>> 2- Make the Jira QA script spot that there is a pull request
>>> available
>>>>> and
>>>>>> not build it.
>>>>>>
>>>>>> I'm wondering if folks would be ok with only having patches
>> submitted
>>>> via
>>>>>> pull requests or if we should continue to support the old Jira QA.
>>>>>>
>>>>>
>>>>> I am +1 on only having patches submitted via PRs, it's simpler to
>> only
>>>> have
>>>>> to support one method. Thanks Flavio for making this happen!
>>>>>
>>>>>
>>>>> -rgs
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers
>>> Michael.
>>>
>>
Re: [DISCUSS] QA github pre-commit queue
Posted by Patrick Hunt <ph...@apache.org>.
What are the implications of moving away from JIRA patches? Any legal/IP?
Also PRs are through github.com, which is not infra owned by Apache. If
that service ever goes away we'll lose that information. What are other
projects doing in this regard? Any impact on our workflows outside of
qabot? e.g. release other other activity tracking?
Patrick
On Tue, Nov 8, 2016 at 6:37 PM, Flavio P JUNQUEIRA <fp...@apache.org> wrote:
> I don't have any strong argument for keeping the Jira patches other than
> the fact that this is what we have been doing since the project was
> created. If there is anyone who do not want to use github in the community,
> please speak up.
>
> -Flavio
>
> On Mon, Nov 7, 2016 at 9:49 AM, Michael Han <ha...@cloudera.com> wrote:
>
> > +1 for disabling jira qa and only support pull request for code change
> > contributions. Besides making support easier this approach is also
> aligned
> > with what Spark and Kafka is doing, and being consistent across Apache
> > projects regarding how to use PR seems a good thing to do.
> >
> > >> have the tool upload the *.patch file to Jira for archiving purposes.
> > I think nothing will prevent a user submit a patch file to JIRA with our
> > script changes, so the functionality of archiving patches will still
> work.
> > Though, I noticed that Kafka [1] and Spark [2] explicitly stated that do
> > not include patch file in JIRA for code contributions, so probably we'd
> do
> > this too for consistency purpose? Are there any benefit of archiving
> > patches given we prefer (or actually require) pull request instead of
> > patches?
> >
> > [1]
> > https://cwiki.apache.org/confluence/display/KAFKA/
> > Contributing+Code+Changes#ContributingCodeChanges-PullRequest
> > [2]
> > https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark#
> > ContributingtoSpark-PullRequest
> >
> > On Mon, Nov 7, 2016 at 8:04 AM, Edward Ribeiro <edward.ribeiro@gmail.com
> >
> > wrote:
> >
> > > I am +1 about having patches submitted via PRs. IMHO, we should disable
> > the
> > > Jira QA altogether, but have the tool upload the *.patch file to Jira
> for
> > > archiving purposes.
> > >
> > > On Sun, Nov 6, 2016 at 6:42 PM, Raúl Gutiérrez Segalés <
> > > rgs@itevenworks.net>
> > > wrote:
> > >
> > > > On 6 November 2016 at 11:54, Flavio Junqueira <fp...@apache.org>
> wrote:
> > > >
> > > > > ZOOKEEPER-2624 has been merged, thank Raul, Ben and Michael for
> > > > reviewing.
> > > > >
> > > > > The QA for pull requests should be working for pull requests agains
> > > > > master, but let's keep an eye and polish any rough edges that might
> > > still
> > > > > be there.
> > > > >
> > > > > With ZOOKEEPER-2624 in, there is one last major decision we need to
> > > make
> > > > > to wrap this up. The pull request QA currently do not make a jira
> > patch
> > > > > available. This is intentional because making it patch available
> will
> > > > > trigger the original Jira QA, which will be confusing because we
> will
> > > > see a
> > > > > failure (I haven't tested, but I think that's what's going to
> > happen).
> > > If
> > > > > we change the script to make the Jira patch available, then we need
> > to
> > > > > either:
> > > > >
> > > > > 1- Disable the Jira QA altogether, which means that we will only
> have
> > > > pull
> > > > > request QA available
> > > > > 2- Make the Jira QA script spot that there is a pull request
> > available
> > > > and
> > > > > not build it.
> > > > >
> > > > > I'm wondering if folks would be ok with only having patches
> submitted
> > > via
> > > > > pull requests or if we should continue to support the old Jira QA.
> > > > >
> > > >
> > > > I am +1 on only having patches submitted via PRs, it's simpler to
> only
> > > have
> > > > to support one method. Thanks Flavio for making this happen!
> > > >
> > > >
> > > > -rgs
> > > >
> > >
> >
> >
> >
> > --
> > Cheers
> > Michael.
> >
>
Re: [DISCUSS] QA github pre-commit queue
Posted by Flavio P JUNQUEIRA <fp...@apache.org>.
I don't have any strong argument for keeping the Jira patches other than
the fact that this is what we have been doing since the project was
created. If there is anyone who do not want to use github in the community,
please speak up.
-Flavio
On Mon, Nov 7, 2016 at 9:49 AM, Michael Han <ha...@cloudera.com> wrote:
> +1 for disabling jira qa and only support pull request for code change
> contributions. Besides making support easier this approach is also aligned
> with what Spark and Kafka is doing, and being consistent across Apache
> projects regarding how to use PR seems a good thing to do.
>
> >> have the tool upload the *.patch file to Jira for archiving purposes.
> I think nothing will prevent a user submit a patch file to JIRA with our
> script changes, so the functionality of archiving patches will still work.
> Though, I noticed that Kafka [1] and Spark [2] explicitly stated that do
> not include patch file in JIRA for code contributions, so probably we'd do
> this too for consistency purpose? Are there any benefit of archiving
> patches given we prefer (or actually require) pull request instead of
> patches?
>
> [1]
> https://cwiki.apache.org/confluence/display/KAFKA/
> Contributing+Code+Changes#ContributingCodeChanges-PullRequest
> [2]
> https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark#
> ContributingtoSpark-PullRequest
>
> On Mon, Nov 7, 2016 at 8:04 AM, Edward Ribeiro <ed...@gmail.com>
> wrote:
>
> > I am +1 about having patches submitted via PRs. IMHO, we should disable
> the
> > Jira QA altogether, but have the tool upload the *.patch file to Jira for
> > archiving purposes.
> >
> > On Sun, Nov 6, 2016 at 6:42 PM, Raúl Gutiérrez Segalés <
> > rgs@itevenworks.net>
> > wrote:
> >
> > > On 6 November 2016 at 11:54, Flavio Junqueira <fp...@apache.org> wrote:
> > >
> > > > ZOOKEEPER-2624 has been merged, thank Raul, Ben and Michael for
> > > reviewing.
> > > >
> > > > The QA for pull requests should be working for pull requests agains
> > > > master, but let's keep an eye and polish any rough edges that might
> > still
> > > > be there.
> > > >
> > > > With ZOOKEEPER-2624 in, there is one last major decision we need to
> > make
> > > > to wrap this up. The pull request QA currently do not make a jira
> patch
> > > > available. This is intentional because making it patch available will
> > > > trigger the original Jira QA, which will be confusing because we will
> > > see a
> > > > failure (I haven't tested, but I think that's what's going to
> happen).
> > If
> > > > we change the script to make the Jira patch available, then we need
> to
> > > > either:
> > > >
> > > > 1- Disable the Jira QA altogether, which means that we will only have
> > > pull
> > > > request QA available
> > > > 2- Make the Jira QA script spot that there is a pull request
> available
> > > and
> > > > not build it.
> > > >
> > > > I'm wondering if folks would be ok with only having patches submitted
> > via
> > > > pull requests or if we should continue to support the old Jira QA.
> > > >
> > >
> > > I am +1 on only having patches submitted via PRs, it's simpler to only
> > have
> > > to support one method. Thanks Flavio for making this happen!
> > >
> > >
> > > -rgs
> > >
> >
>
>
>
> --
> Cheers
> Michael.
>
Re: [DISCUSS] QA github pre-commit queue
Posted by Michael Han <ha...@cloudera.com>.
+1 for disabling jira qa and only support pull request for code change
contributions. Besides making support easier this approach is also aligned
with what Spark and Kafka is doing, and being consistent across Apache
projects regarding how to use PR seems a good thing to do.
>> have the tool upload the *.patch file to Jira for archiving purposes.
I think nothing will prevent a user submit a patch file to JIRA with our
script changes, so the functionality of archiving patches will still work.
Though, I noticed that Kafka [1] and Spark [2] explicitly stated that do
not include patch file in JIRA for code contributions, so probably we'd do
this too for consistency purpose? Are there any benefit of archiving
patches given we prefer (or actually require) pull request instead of
patches?
[1]
https://cwiki.apache.org/confluence/display/KAFKA/Contributing+Code+Changes#ContributingCodeChanges-PullRequest
[2]
https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark#ContributingtoSpark-PullRequest
On Mon, Nov 7, 2016 at 8:04 AM, Edward Ribeiro <ed...@gmail.com>
wrote:
> I am +1 about having patches submitted via PRs. IMHO, we should disable the
> Jira QA altogether, but have the tool upload the *.patch file to Jira for
> archiving purposes.
>
> On Sun, Nov 6, 2016 at 6:42 PM, Raúl Gutiérrez Segalés <
> rgs@itevenworks.net>
> wrote:
>
> > On 6 November 2016 at 11:54, Flavio Junqueira <fp...@apache.org> wrote:
> >
> > > ZOOKEEPER-2624 has been merged, thank Raul, Ben and Michael for
> > reviewing.
> > >
> > > The QA for pull requests should be working for pull requests agains
> > > master, but let's keep an eye and polish any rough edges that might
> still
> > > be there.
> > >
> > > With ZOOKEEPER-2624 in, there is one last major decision we need to
> make
> > > to wrap this up. The pull request QA currently do not make a jira patch
> > > available. This is intentional because making it patch available will
> > > trigger the original Jira QA, which will be confusing because we will
> > see a
> > > failure (I haven't tested, but I think that's what's going to happen).
> If
> > > we change the script to make the Jira patch available, then we need to
> > > either:
> > >
> > > 1- Disable the Jira QA altogether, which means that we will only have
> > pull
> > > request QA available
> > > 2- Make the Jira QA script spot that there is a pull request available
> > and
> > > not build it.
> > >
> > > I'm wondering if folks would be ok with only having patches submitted
> via
> > > pull requests or if we should continue to support the old Jira QA.
> > >
> >
> > I am +1 on only having patches submitted via PRs, it's simpler to only
> have
> > to support one method. Thanks Flavio for making this happen!
> >
> >
> > -rgs
> >
>
--
Cheers
Michael.
Re: [DISCUSS] QA github pre-commit queue
Posted by Edward Ribeiro <ed...@gmail.com>.
I am +1 about having patches submitted via PRs. IMHO, we should disable the
Jira QA altogether, but have the tool upload the *.patch file to Jira for
archiving purposes.
On Sun, Nov 6, 2016 at 6:42 PM, Raúl Gutiérrez Segalés <rg...@itevenworks.net>
wrote:
> On 6 November 2016 at 11:54, Flavio Junqueira <fp...@apache.org> wrote:
>
> > ZOOKEEPER-2624 has been merged, thank Raul, Ben and Michael for
> reviewing.
> >
> > The QA for pull requests should be working for pull requests agains
> > master, but let's keep an eye and polish any rough edges that might still
> > be there.
> >
> > With ZOOKEEPER-2624 in, there is one last major decision we need to make
> > to wrap this up. The pull request QA currently do not make a jira patch
> > available. This is intentional because making it patch available will
> > trigger the original Jira QA, which will be confusing because we will
> see a
> > failure (I haven't tested, but I think that's what's going to happen). If
> > we change the script to make the Jira patch available, then we need to
> > either:
> >
> > 1- Disable the Jira QA altogether, which means that we will only have
> pull
> > request QA available
> > 2- Make the Jira QA script spot that there is a pull request available
> and
> > not build it.
> >
> > I'm wondering if folks would be ok with only having patches submitted via
> > pull requests or if we should continue to support the old Jira QA.
> >
>
> I am +1 on only having patches submitted via PRs, it's simpler to only have
> to support one method. Thanks Flavio for making this happen!
>
>
> -rgs
>
Re: [DISCUSS] QA github pre-commit queue
Posted by Raúl Gutiérrez Segalés <rg...@itevenworks.net>.
On 6 November 2016 at 11:54, Flavio Junqueira <fp...@apache.org> wrote:
> ZOOKEEPER-2624 has been merged, thank Raul, Ben and Michael for reviewing.
>
> The QA for pull requests should be working for pull requests agains
> master, but let's keep an eye and polish any rough edges that might still
> be there.
>
> With ZOOKEEPER-2624 in, there is one last major decision we need to make
> to wrap this up. The pull request QA currently do not make a jira patch
> available. This is intentional because making it patch available will
> trigger the original Jira QA, which will be confusing because we will see a
> failure (I haven't tested, but I think that's what's going to happen). If
> we change the script to make the Jira patch available, then we need to
> either:
>
> 1- Disable the Jira QA altogether, which means that we will only have pull
> request QA available
> 2- Make the Jira QA script spot that there is a pull request available and
> not build it.
>
> I'm wondering if folks would be ok with only having patches submitted via
> pull requests or if we should continue to support the old Jira QA.
>
I am +1 on only having patches submitted via PRs, it's simpler to only have
to support one method. Thanks Flavio for making this happen!
-rgs
[DISCUSS] QA github pre-commit queue
Posted by Flavio Junqueira <fp...@apache.org>.
ZOOKEEPER-2624 has been merged, thank Raul, Ben and Michael for reviewing.
The QA for pull requests should be working for pull requests agains master, but let's keep an eye and polish any rough edges that might still be there.
With ZOOKEEPER-2624 in, there is one last major decision we need to make to wrap this up. The pull request QA currently do not make a jira patch available. This is intentional because making it patch available will trigger the original Jira QA, which will be confusing because we will see a failure (I haven't tested, but I think that's what's going to happen). If we change the script to make the Jira patch available, then we need to either:
1- Disable the Jira QA altogether, which means that we will only have pull request QA available
2- Make the Jira QA script spot that there is a pull request available and not build it.
I'm wondering if folks would be ok with only having patches submitted via pull requests or if we should continue to support the old Jira QA.
Thanks,
-Flavio
> On 02 Nov 2016, at 15:58, Flavio Junqueira <fp...@apache.org> wrote:
>
> Can I get reviews on ZOOKEEPER-2624/Pull Request #97, please? Once that gets in, we will have pull request QA working.
>
> Thanks,
> -Flavio
>
>> On 31 Oct 2016, at 18:26, Edward Ribeiro <ed...@gmail.com> wrote:
>>
>> My comments below:
>>
>> On Mon, Oct 31, 2016 at 4:07 PM, Flavio Junqueira <fp...@apache.org> wrote:
>>
>>>
>>>
>> Feel free to contribute to my changes and suggest a different way in the
>>> jira. We can definitely work together on this, I just want to have this
>>> working soon.
>>>
>>
>> Ok. I don't want to slow down your current work in progress, so I will try
>> to see IF/WHAT I can contribute, but will let you know before hand. :)
>>
>>
>>
>>>
>>> The script is bash, not python.
>>
>>
>> Yup, in fact, I wrote the script with the intention of adding the option
>> of attaching the diff to the JIRA issue to zk-merge-pr.py tool. It woud be
>> for the sake of documeting the patch in the JIRA. Maybe I will create a new
>> issue proposing this once we have the other things sorted out, and only if
>> you guys think this is worth doing.
>>
>>
>>
>>> It doesn't make it patch available mainly because if we make it patch
>>> available, then it will trigger the Jira QA, which will find no patch. It
>>> is a bit messy to trigger this second build, so I'm reluctant in doing it.
>>> I can see two options:
>>>
>>> - Only do github pull requests, in which case "Patch Available" in our
>>> workflow means pull request available
>>> - Somehow detect that there is a pull request and no trigger the Jira QA
>>>
>>
>> IMHO, the the first option is less brittle and effective.
>>
>> Edward
>
Re: QA github pre-commit queue
Posted by Flavio Junqueira <fp...@apache.org>.
Can I get reviews on ZOOKEEPER-2624/Pull Request #97, please? Once that gets in, we will have pull request QA working.
Thanks,
-Flavio
> On 31 Oct 2016, at 18:26, Edward Ribeiro <ed...@gmail.com> wrote:
>
> My comments below:
>
> On Mon, Oct 31, 2016 at 4:07 PM, Flavio Junqueira <fp...@apache.org> wrote:
>
>>
>>
> Feel free to contribute to my changes and suggest a different way in the
>> jira. We can definitely work together on this, I just want to have this
>> working soon.
>>
>
> Ok. I don't want to slow down your current work in progress, so I will try
> to see IF/WHAT I can contribute, but will let you know before hand. :)
>
>
>
>>
>> The script is bash, not python.
>
>
> Yup, in fact, I wrote the script with the intention of adding the option
> of attaching the diff to the JIRA issue to zk-merge-pr.py tool. It woud be
> for the sake of documeting the patch in the JIRA. Maybe I will create a new
> issue proposing this once we have the other things sorted out, and only if
> you guys think this is worth doing.
>
>
>
>> It doesn't make it patch available mainly because if we make it patch
>> available, then it will trigger the Jira QA, which will find no patch. It
>> is a bit messy to trigger this second build, so I'm reluctant in doing it.
>> I can see two options:
>>
>> - Only do github pull requests, in which case "Patch Available" in our
>> workflow means pull request available
>> - Somehow detect that there is a pull request and no trigger the Jira QA
>>
>
> IMHO, the the first option is less brittle and effective.
>
> Edward
Re: QA github pre-commit queue
Posted by Edward Ribeiro <ed...@gmail.com>.
My comments below:
On Mon, Oct 31, 2016 at 4:07 PM, Flavio Junqueira <fp...@apache.org> wrote:
>
>
Feel free to contribute to my changes and suggest a different way in the
> jira. We can definitely work together on this, I just want to have this
> working soon.
>
Ok. I don't want to slow down your current work in progress, so I will try
to see IF/WHAT I can contribute, but will let you know before hand. :)
>
> The script is bash, not python.
Yup, in fact, I wrote the script with the intention of adding the option
of attaching the diff to the JIRA issue to zk-merge-pr.py tool. It woud be
for the sake of documeting the patch in the JIRA. Maybe I will create a new
issue proposing this once we have the other things sorted out, and only if
you guys think this is worth doing.
> It doesn't make it patch available mainly because if we make it patch
> available, then it will trigger the Jira QA, which will find no patch. It
> is a bit messy to trigger this second build, so I'm reluctant in doing it.
> I can see two options:
>
> - Only do github pull requests, in which case "Patch Available" in our
> workflow means pull request available
> - Somehow detect that there is a pull request and no trigger the Jira QA
>
IMHO, the the first option is less brittle and effective.
Edward
Re: QA github pre-commit queue
Posted by Flavio Junqueira <fp...@apache.org>.
I have created ZOOKEEPER-2624 for this and have adapted the existing script to work with the git pull request. Currently, I have a separate script, but there is a lot of duplication, so it sounds very plausible to merge them.
The pull request for the jira has lots of meaningless commits because I was testing my changes. The current state is that I'm able to trigger and produce a report to the jira as we have with the jira QA. If we are to merge these changes in, then I'll close the pull request and resubmit the changes. Feel free to contribute to my changes and suggest a different way in the jira. We can definitely work together on this, I just want to have this working soon.
The script is bash, not python. It doesn't make it patch available mainly because if we make it patch available, then it will trigger the Jira QA, which will find no patch. It is a bit messy to trigger this second build, so I'm reluctant in doing it. I can see two options:
- Only do github pull requests, in which case "Patch Available" in our workflow means pull request available
- Somehow detect that there is a pull request and no trigger the Jira QA
-Flavio
> On 31 Oct 2016, at 17:18, Edward Ribeiro <ed...@gmail.com> wrote:
>
> Hi Flavio,
>
> Nice you have mentioned that 'cause I had written a small python script
> last Friday that gets the Github PR diff and post it on JIRA as an
> attachement. It's a git diff, not a svn one, but the jenkins processing
> queue is applying the patches to git now, right?
>
> https://gist.github.com/eribeiro/be42ff9dcbc50ebd4b2779ef9f866cba
>
> I guess we can incorporate parts of the script above in the QA queue or
> zk-merge-pr.py. It doesn't set up the issue as 'Patch Available', but it
> should be easy to do this. Also, it doesn't cancel the patch if the PR is
> closed, but I guess it can also be done (although I am afraid I don't know
> how to do this automatically).
>
> The zk-merge-pr.py automatically resolve the jira issue once the PR is
> merged.
>
> Edward
>
> On Sat, Oct 29, 2016 at 1:23 PM, Flavio Junqueira <fp...@apache.org> wrote:
>
>> Another thing I forgot to mention and I noticed we are missing is to make
>> a jira patch available when a pull request is submitted and cancel the
>> patch if the pull request is closed without merging. I think there is a way
>> of doing it. It should also be possible to resolve the jira automatically
>> upon committing the pull request.
>>
>> -Flavio
>>
>>> On 28 Oct 2016, at 15:14, Flavio Junqueira <fp...@apache.org> wrote:
>>>
>>> Here is my progress so far. I managed to get the build to trigger with a
>> pull request and pull request changes:
>>>
>>> https://builds.apache.org/view/PreCommit%20Builds/job/PreCom
>> mit-ZOOKEEPER-github-pr-build/
>>>
>>> I had to hack into it a bit because our original pre-commit build is
>> really focused on getting patch files from jira, applying the patch, and
>> building it (check src/java/test/bin/test-patch.sh). I hardcoded the
>> build commands into the queue configuration, which works but makes it hard
>> for others without access to jenkins to contribute, so moving forward we
>> should script it.
>>>
>>> There is clearly some polishing to be done, so please report back so
>> that we can try to fix it.
>>>
>>> -Flavio
>>>
>>>> On 27 Oct 2016, at 22:24, Flavio Junqueira <fp...@apache.org> wrote:
>>>>
>>>> Yeah, I tried to trigger the 761 manually and it didn't work. I need to
>> work on the manual trigger.
>>>>
>>>> The issue with your PR 94 is likely to be a bug in the config that I
>> think I fixed now. I need to create a test PR to debug it.
>>>>
>>>> One problem is that builds.apache.org <http://builds.apache.org/> is
>> super slow, so it is difficult to work on the configuration right now. I'll
>> work some more on my morning because it shouldn't be as busy.
>>>>
>>>> -Flavio
>>>>
>>>>> On 27 Oct 2016, at 22:19, Michael Han <ha...@cloudera.com> wrote:
>>>>>
>>>>> I saw the pre-commit build from the new bot (
>>>>> https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/1/)
>> for
>>>>> ZOOKEEPER-761. There are two issues:
>>>>>
>>>>> * The test does not run, because "[exec] ZOOKEEPER-761 is not "Patch
>>>>> Available". Exiting."
>>>>> * The build result was sent to dev list, but the result was not posted
>> on
>>>>> JIRA, as previous build bot did.
>>>>>
>>>>> Still no sign of pre-commit build triggered by my PR94, btw.
>>>>>
>>>>> On Thu, Oct 27, 2016 at 12:07 PM, Benjamin Reed <br...@apache.org>
>> wrote:
>>>>>
>>>>>> i also pushed a new version for
>>>>>> https://issues.apache.org/jira/browse/ZOOKEEPER-761 although that one
>>>>>> might
>>>>>> be tricky since there are attached patches and a pr. should the pr
>> still be
>>>>>> qaed?
>>>>>>
>>>>>>
>>>>>> On Thu, Oct 27, 2016 at 12:04 PM, Michael Han <ha...@cloudera.com>
>> wrote:
>>>>>>
>>>>>>> Created PR94 to ZOOKEEPER-2014. It's been 2 hours, and no QA bot
>>>>>> activity.
>>>>>>>
>>>>>>> On Thu, Oct 27, 2016 at 9:05 AM, Flavio Junqueira <fp...@apache.org>
>>>>>> wrote:
>>>>>>>
>>>>>>>> Ok, I have created this queue: PreCommit-ZOOKEEPER-github-pr-build.
>> I
>>>>>>>> have configured it and would kindly appreciate if anyone could
>> update a
>>>>>>> PR
>>>>>>>> to test it.
>>>>>>>>
>>>>>>>> -Flavio
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 27 Oct 2016, at 16:57, Edward Ribeiro <edward.ribeiro@gmail.com
>>>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Cool! Thanks for the heads up. :)
>>>>>>>>>
>>>>>>>>> Cheers
>>>>>>>>>
>>>>>>>>> Em 27 de out de 2016 1:56 PM, "Flavio Junqueira" <fp...@apache.org>
>>>>>>>> escreveu:
>>>>>>>>>
>>>>>>>>>> There is no need to create an INFRA jira, I'm taking care of it,
>>>>>> stay
>>>>>>>>>> tuned. In the meanwhile, please submit patches as usual through
>> jira
>>>>>>> to
>>>>>>>>>> trigger QA.
>>>>>>>>>>
>>>>>>>>>> -Flavio
>>>>>>>>>>
>>>>>>>>>>> On 27 Oct 2016, at 16:54, Edward Ribeiro <
>> edward.ribeiro@gmail.com
>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Dear community,
>>>>>>>>>>>
>>>>>>>>>>> As part of the github move, we are still lacking the plumbing
>> that
>>>>>>>> allows
>>>>>>>>>>> to run Jenkins CI tests, etc, on open Pull Requests. Please,
>> take a
>>>>>>>> look
>>>>>>>>>> at
>>>>>>>>>>> Kafka pending PR at Github to see what I am referring to.
>>>>>>>>>>>
>>>>>>>>>>> Any committer could open an INFRA JIRA to address this?
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>> Eddie
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Cheers
>>>>>>> Michael.
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cheers
>>>>> Michael.
>>>>
>>>
>>
>>
Re: QA github pre-commit queue
Posted by Edward Ribeiro <ed...@gmail.com>.
Hi Flavio,
Nice you have mentioned that 'cause I had written a small python script
last Friday that gets the Github PR diff and post it on JIRA as an
attachement. It's a git diff, not a svn one, but the jenkins processing
queue is applying the patches to git now, right?
https://gist.github.com/eribeiro/be42ff9dcbc50ebd4b2779ef9f866cba
I guess we can incorporate parts of the script above in the QA queue or
zk-merge-pr.py. It doesn't set up the issue as 'Patch Available', but it
should be easy to do this. Also, it doesn't cancel the patch if the PR is
closed, but I guess it can also be done (although I am afraid I don't know
how to do this automatically).
The zk-merge-pr.py automatically resolve the jira issue once the PR is
merged.
Edward
On Sat, Oct 29, 2016 at 1:23 PM, Flavio Junqueira <fp...@apache.org> wrote:
> Another thing I forgot to mention and I noticed we are missing is to make
> a jira patch available when a pull request is submitted and cancel the
> patch if the pull request is closed without merging. I think there is a way
> of doing it. It should also be possible to resolve the jira automatically
> upon committing the pull request.
>
> -Flavio
>
> > On 28 Oct 2016, at 15:14, Flavio Junqueira <fp...@apache.org> wrote:
> >
> > Here is my progress so far. I managed to get the build to trigger with a
> pull request and pull request changes:
> >
> > https://builds.apache.org/view/PreCommit%20Builds/job/PreCom
> mit-ZOOKEEPER-github-pr-build/
> >
> > I had to hack into it a bit because our original pre-commit build is
> really focused on getting patch files from jira, applying the patch, and
> building it (check src/java/test/bin/test-patch.sh). I hardcoded the
> build commands into the queue configuration, which works but makes it hard
> for others without access to jenkins to contribute, so moving forward we
> should script it.
> >
> > There is clearly some polishing to be done, so please report back so
> that we can try to fix it.
> >
> > -Flavio
> >
> >> On 27 Oct 2016, at 22:24, Flavio Junqueira <fp...@apache.org> wrote:
> >>
> >> Yeah, I tried to trigger the 761 manually and it didn't work. I need to
> work on the manual trigger.
> >>
> >> The issue with your PR 94 is likely to be a bug in the config that I
> think I fixed now. I need to create a test PR to debug it.
> >>
> >> One problem is that builds.apache.org <http://builds.apache.org/> is
> super slow, so it is difficult to work on the configuration right now. I'll
> work some more on my morning because it shouldn't be as busy.
> >>
> >> -Flavio
> >>
> >>> On 27 Oct 2016, at 22:19, Michael Han <ha...@cloudera.com> wrote:
> >>>
> >>> I saw the pre-commit build from the new bot (
> >>> https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/1/)
> for
> >>> ZOOKEEPER-761. There are two issues:
> >>>
> >>> * The test does not run, because "[exec] ZOOKEEPER-761 is not "Patch
> >>> Available". Exiting."
> >>> * The build result was sent to dev list, but the result was not posted
> on
> >>> JIRA, as previous build bot did.
> >>>
> >>> Still no sign of pre-commit build triggered by my PR94, btw.
> >>>
> >>> On Thu, Oct 27, 2016 at 12:07 PM, Benjamin Reed <br...@apache.org>
> wrote:
> >>>
> >>>> i also pushed a new version for
> >>>> https://issues.apache.org/jira/browse/ZOOKEEPER-761 although that one
> >>>> might
> >>>> be tricky since there are attached patches and a pr. should the pr
> still be
> >>>> qaed?
> >>>>
> >>>>
> >>>> On Thu, Oct 27, 2016 at 12:04 PM, Michael Han <ha...@cloudera.com>
> wrote:
> >>>>
> >>>>> Created PR94 to ZOOKEEPER-2014. It's been 2 hours, and no QA bot
> >>>> activity.
> >>>>>
> >>>>> On Thu, Oct 27, 2016 at 9:05 AM, Flavio Junqueira <fp...@apache.org>
> >>>> wrote:
> >>>>>
> >>>>>> Ok, I have created this queue: PreCommit-ZOOKEEPER-github-pr-build.
> I
> >>>>>> have configured it and would kindly appreciate if anyone could
> update a
> >>>>> PR
> >>>>>> to test it.
> >>>>>>
> >>>>>> -Flavio
> >>>>>>
> >>>>>>
> >>>>>>> On 27 Oct 2016, at 16:57, Edward Ribeiro <edward.ribeiro@gmail.com
> >
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> Cool! Thanks for the heads up. :)
> >>>>>>>
> >>>>>>> Cheers
> >>>>>>>
> >>>>>>> Em 27 de out de 2016 1:56 PM, "Flavio Junqueira" <fp...@apache.org>
> >>>>>> escreveu:
> >>>>>>>
> >>>>>>>> There is no need to create an INFRA jira, I'm taking care of it,
> >>>> stay
> >>>>>>>> tuned. In the meanwhile, please submit patches as usual through
> jira
> >>>>> to
> >>>>>>>> trigger QA.
> >>>>>>>>
> >>>>>>>> -Flavio
> >>>>>>>>
> >>>>>>>>> On 27 Oct 2016, at 16:54, Edward Ribeiro <
> edward.ribeiro@gmail.com
> >>>>>
> >>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> Dear community,
> >>>>>>>>>
> >>>>>>>>> As part of the github move, we are still lacking the plumbing
> that
> >>>>>> allows
> >>>>>>>>> to run Jenkins CI tests, etc, on open Pull Requests. Please,
> take a
> >>>>>> look
> >>>>>>>> at
> >>>>>>>>> Kafka pending PR at Github to see what I am referring to.
> >>>>>>>>>
> >>>>>>>>> Any committer could open an INFRA JIRA to address this?
> >>>>>>>>>
> >>>>>>>>> Best regards,
> >>>>>>>>> Eddie
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Cheers
> >>>>> Michael.
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Cheers
> >>> Michael.
> >>
> >
>
>
Re: QA github pre-commit queue
Posted by Flavio Junqueira <fp...@apache.org>.
Another thing I forgot to mention and I noticed we are missing is to make a jira patch available when a pull request is submitted and cancel the patch if the pull request is closed without merging. I think there is a way of doing it. It should also be possible to resolve the jira automatically upon committing the pull request.
-Flavio
> On 28 Oct 2016, at 15:14, Flavio Junqueira <fp...@apache.org> wrote:
>
> Here is my progress so far. I managed to get the build to trigger with a pull request and pull request changes:
>
> https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-ZOOKEEPER-github-pr-build/
>
> I had to hack into it a bit because our original pre-commit build is really focused on getting patch files from jira, applying the patch, and building it (check src/java/test/bin/test-patch.sh). I hardcoded the build commands into the queue configuration, which works but makes it hard for others without access to jenkins to contribute, so moving forward we should script it.
>
> There is clearly some polishing to be done, so please report back so that we can try to fix it.
>
> -Flavio
>
>> On 27 Oct 2016, at 22:24, Flavio Junqueira <fp...@apache.org> wrote:
>>
>> Yeah, I tried to trigger the 761 manually and it didn't work. I need to work on the manual trigger.
>>
>> The issue with your PR 94 is likely to be a bug in the config that I think I fixed now. I need to create a test PR to debug it.
>>
>> One problem is that builds.apache.org <http://builds.apache.org/> is super slow, so it is difficult to work on the configuration right now. I'll work some more on my morning because it shouldn't be as busy.
>>
>> -Flavio
>>
>>> On 27 Oct 2016, at 22:19, Michael Han <ha...@cloudera.com> wrote:
>>>
>>> I saw the pre-commit build from the new bot (
>>> https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/1/) for
>>> ZOOKEEPER-761. There are two issues:
>>>
>>> * The test does not run, because "[exec] ZOOKEEPER-761 is not "Patch
>>> Available". Exiting."
>>> * The build result was sent to dev list, but the result was not posted on
>>> JIRA, as previous build bot did.
>>>
>>> Still no sign of pre-commit build triggered by my PR94, btw.
>>>
>>> On Thu, Oct 27, 2016 at 12:07 PM, Benjamin Reed <br...@apache.org> wrote:
>>>
>>>> i also pushed a new version for
>>>> https://issues.apache.org/jira/browse/ZOOKEEPER-761 although that one
>>>> might
>>>> be tricky since there are attached patches and a pr. should the pr still be
>>>> qaed?
>>>>
>>>>
>>>> On Thu, Oct 27, 2016 at 12:04 PM, Michael Han <ha...@cloudera.com> wrote:
>>>>
>>>>> Created PR94 to ZOOKEEPER-2014. It's been 2 hours, and no QA bot
>>>> activity.
>>>>>
>>>>> On Thu, Oct 27, 2016 at 9:05 AM, Flavio Junqueira <fp...@apache.org>
>>>> wrote:
>>>>>
>>>>>> Ok, I have created this queue: PreCommit-ZOOKEEPER-github-pr-build. I
>>>>>> have configured it and would kindly appreciate if anyone could update a
>>>>> PR
>>>>>> to test it.
>>>>>>
>>>>>> -Flavio
>>>>>>
>>>>>>
>>>>>>> On 27 Oct 2016, at 16:57, Edward Ribeiro <ed...@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Cool! Thanks for the heads up. :)
>>>>>>>
>>>>>>> Cheers
>>>>>>>
>>>>>>> Em 27 de out de 2016 1:56 PM, "Flavio Junqueira" <fp...@apache.org>
>>>>>> escreveu:
>>>>>>>
>>>>>>>> There is no need to create an INFRA jira, I'm taking care of it,
>>>> stay
>>>>>>>> tuned. In the meanwhile, please submit patches as usual through jira
>>>>> to
>>>>>>>> trigger QA.
>>>>>>>>
>>>>>>>> -Flavio
>>>>>>>>
>>>>>>>>> On 27 Oct 2016, at 16:54, Edward Ribeiro <edward.ribeiro@gmail.com
>>>>>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Dear community,
>>>>>>>>>
>>>>>>>>> As part of the github move, we are still lacking the plumbing that
>>>>>> allows
>>>>>>>>> to run Jenkins CI tests, etc, on open Pull Requests. Please, take a
>>>>>> look
>>>>>>>> at
>>>>>>>>> Kafka pending PR at Github to see what I am referring to.
>>>>>>>>>
>>>>>>>>> Any committer could open an INFRA JIRA to address this?
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Eddie
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cheers
>>>>> Michael.
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers
>>> Michael.
>>
>
Re: QA github pre-commit queue
Posted by Flavio Junqueira <fp...@apache.org>.
Here is my progress so far. I managed to get the build to trigger with a pull request and pull request changes:
https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-ZOOKEEPER-github-pr-build/
I had to hack into it a bit because our original pre-commit build is really focused on getting patch files from jira, applying the patch, and building it (check src/java/test/bin/test-patch.sh). I hardcoded the build commands into the queue configuration, which works but makes it hard for others without access to jenkins to contribute, so moving forward we should script it.
There is clearly some polishing to be done, so please report back so that we can try to fix it.
-Flavio
> On 27 Oct 2016, at 22:24, Flavio Junqueira <fp...@apache.org> wrote:
>
> Yeah, I tried to trigger the 761 manually and it didn't work. I need to work on the manual trigger.
>
> The issue with your PR 94 is likely to be a bug in the config that I think I fixed now. I need to create a test PR to debug it.
>
> One problem is that builds.apache.org <http://builds.apache.org/> is super slow, so it is difficult to work on the configuration right now. I'll work some more on my morning because it shouldn't be as busy.
>
> -Flavio
>
>> On 27 Oct 2016, at 22:19, Michael Han <ha...@cloudera.com> wrote:
>>
>> I saw the pre-commit build from the new bot (
>> https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/1/) for
>> ZOOKEEPER-761. There are two issues:
>>
>> * The test does not run, because "[exec] ZOOKEEPER-761 is not "Patch
>> Available". Exiting."
>> * The build result was sent to dev list, but the result was not posted on
>> JIRA, as previous build bot did.
>>
>> Still no sign of pre-commit build triggered by my PR94, btw.
>>
>> On Thu, Oct 27, 2016 at 12:07 PM, Benjamin Reed <br...@apache.org> wrote:
>>
>>> i also pushed a new version for
>>> https://issues.apache.org/jira/browse/ZOOKEEPER-761 although that one
>>> might
>>> be tricky since there are attached patches and a pr. should the pr still be
>>> qaed?
>>>
>>>
>>> On Thu, Oct 27, 2016 at 12:04 PM, Michael Han <ha...@cloudera.com> wrote:
>>>
>>>> Created PR94 to ZOOKEEPER-2014. It's been 2 hours, and no QA bot
>>> activity.
>>>>
>>>> On Thu, Oct 27, 2016 at 9:05 AM, Flavio Junqueira <fp...@apache.org>
>>> wrote:
>>>>
>>>>> Ok, I have created this queue: PreCommit-ZOOKEEPER-github-pr-build. I
>>>>> have configured it and would kindly appreciate if anyone could update a
>>>> PR
>>>>> to test it.
>>>>>
>>>>> -Flavio
>>>>>
>>>>>
>>>>>> On 27 Oct 2016, at 16:57, Edward Ribeiro <ed...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> Cool! Thanks for the heads up. :)
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>> Em 27 de out de 2016 1:56 PM, "Flavio Junqueira" <fp...@apache.org>
>>>>> escreveu:
>>>>>>
>>>>>>> There is no need to create an INFRA jira, I'm taking care of it,
>>> stay
>>>>>>> tuned. In the meanwhile, please submit patches as usual through jira
>>>> to
>>>>>>> trigger QA.
>>>>>>>
>>>>>>> -Flavio
>>>>>>>
>>>>>>>> On 27 Oct 2016, at 16:54, Edward Ribeiro <edward.ribeiro@gmail.com
>>>>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Dear community,
>>>>>>>>
>>>>>>>> As part of the github move, we are still lacking the plumbing that
>>>>> allows
>>>>>>>> to run Jenkins CI tests, etc, on open Pull Requests. Please, take a
>>>>> look
>>>>>>> at
>>>>>>>> Kafka pending PR at Github to see what I am referring to.
>>>>>>>>
>>>>>>>> Any committer could open an INFRA JIRA to address this?
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Eddie
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Cheers
>>>> Michael.
>>>>
>>>
>>
>>
>>
>> --
>> Cheers
>> Michael.
>
Re: QA github pre-commit queue
Posted by Flavio Junqueira <fp...@apache.org>.
Yeah, I tried to trigger the 761 manually and it didn't work. I need to work on the manual trigger.
The issue with your PR 94 is likely to be a bug in the config that I think I fixed now. I need to create a test PR to debug it.
One problem is that builds.apache.org <http://builds.apache.org/> is super slow, so it is difficult to work on the configuration right now. I'll work some more on my morning because it shouldn't be as busy.
-Flavio
> On 27 Oct 2016, at 22:19, Michael Han <ha...@cloudera.com> wrote:
>
> I saw the pre-commit build from the new bot (
> https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/1/) for
> ZOOKEEPER-761. There are two issues:
>
> * The test does not run, because "[exec] ZOOKEEPER-761 is not "Patch
> Available". Exiting."
> * The build result was sent to dev list, but the result was not posted on
> JIRA, as previous build bot did.
>
> Still no sign of pre-commit build triggered by my PR94, btw.
>
> On Thu, Oct 27, 2016 at 12:07 PM, Benjamin Reed <br...@apache.org> wrote:
>
>> i also pushed a new version for
>> https://issues.apache.org/jira/browse/ZOOKEEPER-761 although that one
>> might
>> be tricky since there are attached patches and a pr. should the pr still be
>> qaed?
>>
>>
>> On Thu, Oct 27, 2016 at 12:04 PM, Michael Han <ha...@cloudera.com> wrote:
>>
>>> Created PR94 to ZOOKEEPER-2014. It's been 2 hours, and no QA bot
>> activity.
>>>
>>> On Thu, Oct 27, 2016 at 9:05 AM, Flavio Junqueira <fp...@apache.org>
>> wrote:
>>>
>>>> Ok, I have created this queue: PreCommit-ZOOKEEPER-github-pr-build. I
>>>> have configured it and would kindly appreciate if anyone could update a
>>> PR
>>>> to test it.
>>>>
>>>> -Flavio
>>>>
>>>>
>>>>> On 27 Oct 2016, at 16:57, Edward Ribeiro <ed...@gmail.com>
>>>> wrote:
>>>>>
>>>>> Cool! Thanks for the heads up. :)
>>>>>
>>>>> Cheers
>>>>>
>>>>> Em 27 de out de 2016 1:56 PM, "Flavio Junqueira" <fp...@apache.org>
>>>> escreveu:
>>>>>
>>>>>> There is no need to create an INFRA jira, I'm taking care of it,
>> stay
>>>>>> tuned. In the meanwhile, please submit patches as usual through jira
>>> to
>>>>>> trigger QA.
>>>>>>
>>>>>> -Flavio
>>>>>>
>>>>>>> On 27 Oct 2016, at 16:54, Edward Ribeiro <edward.ribeiro@gmail.com
>>>
>>>>>> wrote:
>>>>>>>
>>>>>>> Dear community,
>>>>>>>
>>>>>>> As part of the github move, we are still lacking the plumbing that
>>>> allows
>>>>>>> to run Jenkins CI tests, etc, on open Pull Requests. Please, take a
>>>> look
>>>>>> at
>>>>>>> Kafka pending PR at Github to see what I am referring to.
>>>>>>>
>>>>>>> Any committer could open an INFRA JIRA to address this?
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Eddie
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Cheers
>>> Michael.
>>>
>>
>
>
>
> --
> Cheers
> Michael.
Re: QA github pre-commit queue
Posted by Michael Han <ha...@cloudera.com>.
I saw the pre-commit build from the new bot (
https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/1/) for
ZOOKEEPER-761. There are two issues:
* The test does not run, because "[exec] ZOOKEEPER-761 is not "Patch
Available". Exiting."
* The build result was sent to dev list, but the result was not posted on
JIRA, as previous build bot did.
Still no sign of pre-commit build triggered by my PR94, btw.
On Thu, Oct 27, 2016 at 12:07 PM, Benjamin Reed <br...@apache.org> wrote:
> i also pushed a new version for
> https://issues.apache.org/jira/browse/ZOOKEEPER-761 although that one
> might
> be tricky since there are attached patches and a pr. should the pr still be
> qaed?
>
>
> On Thu, Oct 27, 2016 at 12:04 PM, Michael Han <ha...@cloudera.com> wrote:
>
> > Created PR94 to ZOOKEEPER-2014. It's been 2 hours, and no QA bot
> activity.
> >
> > On Thu, Oct 27, 2016 at 9:05 AM, Flavio Junqueira <fp...@apache.org>
> wrote:
> >
> > > Ok, I have created this queue: PreCommit-ZOOKEEPER-github-pr-build. I
> > > have configured it and would kindly appreciate if anyone could update a
> > PR
> > > to test it.
> > >
> > > -Flavio
> > >
> > >
> > > > On 27 Oct 2016, at 16:57, Edward Ribeiro <ed...@gmail.com>
> > > wrote:
> > > >
> > > > Cool! Thanks for the heads up. :)
> > > >
> > > > Cheers
> > > >
> > > > Em 27 de out de 2016 1:56 PM, "Flavio Junqueira" <fp...@apache.org>
> > > escreveu:
> > > >
> > > >> There is no need to create an INFRA jira, I'm taking care of it,
> stay
> > > >> tuned. In the meanwhile, please submit patches as usual through jira
> > to
> > > >> trigger QA.
> > > >>
> > > >> -Flavio
> > > >>
> > > >>> On 27 Oct 2016, at 16:54, Edward Ribeiro <edward.ribeiro@gmail.com
> >
> > > >> wrote:
> > > >>>
> > > >>> Dear community,
> > > >>>
> > > >>> As part of the github move, we are still lacking the plumbing that
> > > allows
> > > >>> to run Jenkins CI tests, etc, on open Pull Requests. Please, take a
> > > look
> > > >> at
> > > >>> Kafka pending PR at Github to see what I am referring to.
> > > >>>
> > > >>> Any committer could open an INFRA JIRA to address this?
> > > >>>
> > > >>> Best regards,
> > > >>> Eddie
> > > >>
> > > >>
> > >
> > >
> >
> >
> > --
> > Cheers
> > Michael.
> >
>
--
Cheers
Michael.
Re: QA github pre-commit queue
Posted by Benjamin Reed <br...@apache.org>.
i also pushed a new version for
https://issues.apache.org/jira/browse/ZOOKEEPER-761 although that one might
be tricky since there are attached patches and a pr. should the pr still be
qaed?
On Thu, Oct 27, 2016 at 12:04 PM, Michael Han <ha...@cloudera.com> wrote:
> Created PR94 to ZOOKEEPER-2014. It's been 2 hours, and no QA bot activity.
>
> On Thu, Oct 27, 2016 at 9:05 AM, Flavio Junqueira <fp...@apache.org> wrote:
>
> > Ok, I have created this queue: PreCommit-ZOOKEEPER-github-pr-build. I
> > have configured it and would kindly appreciate if anyone could update a
> PR
> > to test it.
> >
> > -Flavio
> >
> >
> > > On 27 Oct 2016, at 16:57, Edward Ribeiro <ed...@gmail.com>
> > wrote:
> > >
> > > Cool! Thanks for the heads up. :)
> > >
> > > Cheers
> > >
> > > Em 27 de out de 2016 1:56 PM, "Flavio Junqueira" <fp...@apache.org>
> > escreveu:
> > >
> > >> There is no need to create an INFRA jira, I'm taking care of it, stay
> > >> tuned. In the meanwhile, please submit patches as usual through jira
> to
> > >> trigger QA.
> > >>
> > >> -Flavio
> > >>
> > >>> On 27 Oct 2016, at 16:54, Edward Ribeiro <ed...@gmail.com>
> > >> wrote:
> > >>>
> > >>> Dear community,
> > >>>
> > >>> As part of the github move, we are still lacking the plumbing that
> > allows
> > >>> to run Jenkins CI tests, etc, on open Pull Requests. Please, take a
> > look
> > >> at
> > >>> Kafka pending PR at Github to see what I am referring to.
> > >>>
> > >>> Any committer could open an INFRA JIRA to address this?
> > >>>
> > >>> Best regards,
> > >>> Eddie
> > >>
> > >>
> >
> >
>
>
> --
> Cheers
> Michael.
>
Re: QA github pre-commit queue
Posted by Michael Han <ha...@cloudera.com>.
Created PR94 to ZOOKEEPER-2014. It's been 2 hours, and no QA bot activity.
On Thu, Oct 27, 2016 at 9:05 AM, Flavio Junqueira <fp...@apache.org> wrote:
> Ok, I have created this queue: PreCommit-ZOOKEEPER-github-pr-build. I
> have configured it and would kindly appreciate if anyone could update a PR
> to test it.
>
> -Flavio
>
>
> > On 27 Oct 2016, at 16:57, Edward Ribeiro <ed...@gmail.com>
> wrote:
> >
> > Cool! Thanks for the heads up. :)
> >
> > Cheers
> >
> > Em 27 de out de 2016 1:56 PM, "Flavio Junqueira" <fp...@apache.org>
> escreveu:
> >
> >> There is no need to create an INFRA jira, I'm taking care of it, stay
> >> tuned. In the meanwhile, please submit patches as usual through jira to
> >> trigger QA.
> >>
> >> -Flavio
> >>
> >>> On 27 Oct 2016, at 16:54, Edward Ribeiro <ed...@gmail.com>
> >> wrote:
> >>>
> >>> Dear community,
> >>>
> >>> As part of the github move, we are still lacking the plumbing that
> allows
> >>> to run Jenkins CI tests, etc, on open Pull Requests. Please, take a
> look
> >> at
> >>> Kafka pending PR at Github to see what I am referring to.
> >>>
> >>> Any committer could open an INFRA JIRA to address this?
> >>>
> >>> Best regards,
> >>> Eddie
> >>
> >>
>
>
--
Cheers
Michael.
Re: QA github pre-commit queue
Posted by Flavio Junqueira <fp...@apache.org>.
Ok, I have created this queue: PreCommit-ZOOKEEPER-github-pr-build. I have configured it and would kindly appreciate if anyone could update a PR to test it.
-Flavio
> On 27 Oct 2016, at 16:57, Edward Ribeiro <ed...@gmail.com> wrote:
>
> Cool! Thanks for the heads up. :)
>
> Cheers
>
> Em 27 de out de 2016 1:56 PM, "Flavio Junqueira" <fp...@apache.org> escreveu:
>
>> There is no need to create an INFRA jira, I'm taking care of it, stay
>> tuned. In the meanwhile, please submit patches as usual through jira to
>> trigger QA.
>>
>> -Flavio
>>
>>> On 27 Oct 2016, at 16:54, Edward Ribeiro <ed...@gmail.com>
>> wrote:
>>>
>>> Dear community,
>>>
>>> As part of the github move, we are still lacking the plumbing that allows
>>> to run Jenkins CI tests, etc, on open Pull Requests. Please, take a look
>> at
>>> Kafka pending PR at Github to see what I am referring to.
>>>
>>> Any committer could open an INFRA JIRA to address this?
>>>
>>> Best regards,
>>> Eddie
>>
>>
Re: QA github pre-commit queue
Posted by Edward Ribeiro <ed...@gmail.com>.
Cool! Thanks for the heads up. :)
Cheers
Em 27 de out de 2016 1:56 PM, "Flavio Junqueira" <fp...@apache.org> escreveu:
> There is no need to create an INFRA jira, I'm taking care of it, stay
> tuned. In the meanwhile, please submit patches as usual through jira to
> trigger QA.
>
> -Flavio
>
> > On 27 Oct 2016, at 16:54, Edward Ribeiro <ed...@gmail.com>
> wrote:
> >
> > Dear community,
> >
> > As part of the github move, we are still lacking the plumbing that allows
> > to run Jenkins CI tests, etc, on open Pull Requests. Please, take a look
> at
> > Kafka pending PR at Github to see what I am referring to.
> >
> > Any committer could open an INFRA JIRA to address this?
> >
> > Best regards,
> > Eddie
>
>
Re: QA github pre-commit queue
Posted by Flavio Junqueira <fp...@apache.org>.
There is no need to create an INFRA jira, I'm taking care of it, stay tuned. In the meanwhile, please submit patches as usual through jira to trigger QA.
-Flavio
> On 27 Oct 2016, at 16:54, Edward Ribeiro <ed...@gmail.com> wrote:
>
> Dear community,
>
> As part of the github move, we are still lacking the plumbing that allows
> to run Jenkins CI tests, etc, on open Pull Requests. Please, take a look at
> Kafka pending PR at Github to see what I am referring to.
>
> Any committer could open an INFRA JIRA to address this?
>
> Best regards,
> Eddie