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 <h...@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 <h...@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.ribe...@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 < > >> r...@itevenworks.net> > >> wrote: > >> > >> > On 6 November 2016 at 11:54, Flavio Junqueira <f...@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. >
