Re: [DISCUSS] GitHub PRs without JIRA number
Thanks for doing this! It also looks like "Scan Now" also triggers builds for non-committer's PRs. That's great! On Tue, Sep 10, 2019 at 10:21 PM 张铎(Duo Zhang) wrote: > Actually the job for testing PR is here... > > https://builds.apache.org/job/hadoop-multibranch/ > > I've added the 'Change requests' option(seems I have the permission...), > and then clicked the 'Scan Now', the job for PR-1404 has been scheduled > > > https://builds.apache.org/job/hadoop-multibranch/view/change-requests/job/PR-1404/ > > > The infra team has shutdown the github webhook on scheduling builds > automatically when there are new PRs or new updates to existing PRs, > because this violate the rule that only committers can trigger jenkins > jobs, so we need to click the 'Scan Now' button to trigger builds. And it > is possible to schedule a periodical job to do the scan, for HBase the > interval is 10 minutes, and for hadoop, there are too many branches and > PRs, the job is still running while I'm writing this email, so I think > maybe we should use a greater interval, maybe 20 or 30 minutes? > > Thanks. > > Steve Loughran 于2019年9月10日周二 下午7:36写道： > > > > > > > On Tue, Sep 10, 2019 at 9:07 AM 张铎(Duo Zhang) > > wrote: > > > >> Nits: You can change the jenkins job config to not trigger pre commit > >> build > >> for stale PRs if only the base branch is changed. By default, either the > >> PR > >> itself changed, or the base branch is changed, the branch sources plugin > >> will both trigger a build. You can add a Change requests option, and > >> select > >> 'Ignore rebuilding merge branches when only the target branch changed'. > So > >> the stale PRs will not waste jenkins build resources any more. > >> > >> +1 for this. If old PRs want to be tested by their creator, they can > > rebase. Having a way to ask jenkins to do it on the PR lets other. > > > > > >> And on retesting a PR, just go to the pipeline jenkins job, find the > >> related job for the PR, and click build manually. > >> > >> > >> > > > >1. I like the command approach. Spark has this, and some gerrit > >pipelines do. > >2. I've just tried to do this on a PR ( > >https://github.com/apache/hadoop/pull/1404) but can't see how to. The > >precommit hdfs job only takes the JIRA number and looks for an > attachment, > >judging by the way it is failing to merge things in > > > https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HDFS-Build/27830/ > > > > Is there another build or some trick I should use? > > Ni > > >
Re: [DISCUSS] GitHub PRs without JIRA number
OK, the indexing is finished [Tue Sep 10 14:25:07 UTC 2019] Finished branch indexing. Indexing took 15 min So maybe 30 minutes is better... And we really should cleanup the stale PRs and branches... 张铎(Duo Zhang) 于2019年9月10日周二 下午10:20写道： > Actually the job for testing PR is here... > > https://builds.apache.org/job/hadoop-multibranch/ > > I've added the 'Change requests' option(seems I have the permission...), > and then clicked the 'Scan Now', the job for PR-1404 has been scheduled > > > https://builds.apache.org/job/hadoop-multibranch/view/change-requests/job/PR-1404/ > > > The infra team has shutdown the github webhook on scheduling builds > automatically when there are new PRs or new updates to existing PRs, > because this violate the rule that only committers can trigger jenkins > jobs, so we need to click the 'Scan Now' button to trigger builds. And it > is possible to schedule a periodical job to do the scan, for HBase the > interval is 10 minutes, and for hadoop, there are too many branches and > PRs, the job is still running while I'm writing this email, so I think > maybe we should use a greater interval, maybe 20 or 30 minutes? > > Thanks. > > Steve Loughran 于2019年9月10日周二 下午7:36写道： > >> >> >> On Tue, Sep 10, 2019 at 9:07 AM 张铎(Duo Zhang) >> wrote: >> >>> Nits: You can change the jenkins job config to not trigger pre commit >>> build >>> for stale PRs if only the base branch is changed. By default, either the >>> PR >>> itself changed, or the base branch is changed, the branch sources plugin >>> will both trigger a build. You can add a Change requests option, and >>> select >>> 'Ignore rebuilding merge branches when only the target branch changed'. >>> So >>> the stale PRs will not waste jenkins build resources any more. >>> >>> +1 for this. If old PRs want to be tested by their creator, they can >> rebase. Having a way to ask jenkins to do it on the PR lets other. >> >> >>> And on retesting a PR, just go to the pipeline jenkins job, find the >>> related job for the PR, and click build manually. >>> >>> >>> >> >>1. I like the command approach. Spark has this, and some gerrit >>pipelines do. >>2. I've just tried to do this on a PR ( >>https://github.com/apache/hadoop/pull/1404) but can't see how to. The >>precommit hdfs job only takes the JIRA number and looks for an attachment, >>judging by the way it is failing to merge things in >> >> https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HDFS-Build/27830/ >> >> Is there another build or some trick I should use? >> Ni >> >
Re: [DISCUSS] GitHub PRs without JIRA number
Actually the job for testing PR is here... https://builds.apache.org/job/hadoop-multibranch/ I've added the 'Change requests' option(seems I have the permission...), and then clicked the 'Scan Now', the job for PR-1404 has been scheduled https://builds.apache.org/job/hadoop-multibranch/view/change-requests/job/PR-1404/ The infra team has shutdown the github webhook on scheduling builds automatically when there are new PRs or new updates to existing PRs, because this violate the rule that only committers can trigger jenkins jobs, so we need to click the 'Scan Now' button to trigger builds. And it is possible to schedule a periodical job to do the scan, for HBase the interval is 10 minutes, and for hadoop, there are too many branches and PRs, the job is still running while I'm writing this email, so I think maybe we should use a greater interval, maybe 20 or 30 minutes? Thanks. Steve Loughran 于2019年9月10日周二 下午7:36写道： > > > On Tue, Sep 10, 2019 at 9:07 AM 张铎(Duo Zhang) > wrote: > >> Nits: You can change the jenkins job config to not trigger pre commit >> build >> for stale PRs if only the base branch is changed. By default, either the >> PR >> itself changed, or the base branch is changed, the branch sources plugin >> will both trigger a build. You can add a Change requests option, and >> select >> 'Ignore rebuilding merge branches when only the target branch changed'. So >> the stale PRs will not waste jenkins build resources any more. >> >> +1 for this. If old PRs want to be tested by their creator, they can > rebase. Having a way to ask jenkins to do it on the PR lets other. > > >> And on retesting a PR, just go to the pipeline jenkins job, find the >> related job for the PR, and click build manually. >> >> >> > >1. I like the command approach. Spark has this, and some gerrit >pipelines do. >2. I've just tried to do this on a PR ( >https://github.com/apache/hadoop/pull/1404) but can't see how to. The >precommit hdfs job only takes the JIRA number and looks for an attachment, >judging by the way it is failing to merge things in > > https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HDFS-Build/27830/ > > Is there another build or some trick I should use? > Ni >
Re: [DISCUSS] GitHub PRs without JIRA number
On Tue, Sep 10, 2019 at 9:07 AM 张铎(Duo Zhang) wrote: > Nits: You can change the jenkins job config to not trigger pre commit build > for stale PRs if only the base branch is changed. By default, either the PR > itself changed, or the base branch is changed, the branch sources plugin > will both trigger a build. You can add a Change requests option, and select > 'Ignore rebuilding merge branches when only the target branch changed'. So > the stale PRs will not waste jenkins build resources any more. > > +1 for this. If old PRs want to be tested by their creator, they can rebase. Having a way to ask jenkins to do it on the PR lets other. > And on retesting a PR, just go to the pipeline jenkins job, find the > related job for the PR, and click build manually. > > > 1. I like the command approach. Spark has this, and some gerrit pipelines do. 2. I've just tried to do this on a PR ( https://github.com/apache/hadoop/pull/1404) but can't see how to. The precommit hdfs job only takes the JIRA number and looks for an attachment, judging by the way it is failing to merge things in https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HDFS-Build/27830/ Is there another build or some trick I should use? Ni
Re: [DISCUSS] GitHub PRs without JIRA number
Nits: You can change the jenkins job config to not trigger pre commit build for stale PRs if only the base branch is changed. By default, either the PR itself changed, or the base branch is changed, the branch sources plugin will both trigger a build. You can add a Change requests option, and select 'Ignore rebuilding merge branches when only the target branch changed'. So the stale PRs will not waste jenkins build resources any more. And on retesting a PR, just go to the pipeline jenkins job, find the related job for the PR, and click build manually. Thanks. Akira Ajisaka 于2019年9月10日周二 下午2:30写道： > Thanks all for the discussion. > > I'm +1 for adding PR template and I wrote a patch long ago: > https://issues.apache.org/jira/browse/HADOOP-15184 > > I'm interested in "test this", "retest this", etc. > I'll file a jira for this feature. > > -Akira > > On Thu, Sep 5, 2019 at 4:05 AM Sean Busbey > wrote: > > > We should add a Pull Request Template that specifically calls out the > > expectation that folks need to have a JIRA associated with their PR > > for it to get reviewed. Expectations around time to response and how > > to go about getting attention when things lag would also be good to > > include. (e.g. are folks expected to ping on the jira? are folks > > expected to email a relevant *-dev list?) > > > > If anyone is interested in doing the work to make it so "test this" / > > "retest this" / etc work, open a jira and I'll give you some pointers > > of examples to go off of. We use a plugin to do this for yetus based > > tests in some HBase repos. > > > > On Wed, Sep 4, 2019 at 1:59 PM Wei-Chiu Chuang > > wrote: > > > > > > +general@ > > > > > > > > > On Wed, Aug 28, 2019 at 6:42 AM Wei-Chiu Chuang > > wrote: > > > > > > > I don't think our GitHub integration supports those commands. Ozone > has > > > > its own github integration that can test individual PRs though. > > > > > > > > > > > > > > > > On Tue, Aug 27, 2019 at 12:40 PM Iñigo Goiri > > wrote: > > > > > > > >> I wouldn't go for #3 and always require a JIRA for a PR. > > > >> > > > >> In general, I think we should state the best practices for using > > GitHub > > > >> PRs. > > > >> There were some guidelines but they were kind of open > > > >> For example, adding always a link to the JIRA to the description. > > > >> I think PRs can have a template as a start. > > > >> > > > >> The other thing I would do is to disable the automatic Jenkins > > trigger. > > > >> I've seen the "retest this" and others: > > > >> > > > https://wiki.jenkins.io/display/JENKINS/GitHub+pull+request+builder+plugin > > > >> https://github.com/jenkinsci/ghprb-plugin/blob/master/README.md > > > >> > > > >> > > > >> > > > >> On Tue, Aug 27, 2019 at 10:47 AM Wei-Chiu Chuang < > weic...@apache.org> > > > >> wrote: > > > >> > > > >> > Hi, > > > >> > There are hundreds of GitHub PRs pending review. Many of them just > > sit > > > >> > there wasting Jenkins resources. > > > >> > > > > >> > I suggest: > > > >> > (1) close PRs that went stale (i.e. doesn't compile). Or even > close > > PRs > > > >> > that hasn't been reviewed for more than a year. > > > >> > (1) close PRs that doesn't have a JIRA number. No one is going to > > > >> review a > > > >> > big PR that doesn't have a JIRA anyway. > > > >> > (2) For PRs without JIRA number, file JIRAs for the PR on behalf > of > > the > > > >> > reporter. > > > >> > (3) For typo fixes, merge the PRs directly without a JIRA. IMO, > > this is > > > >> the > > > >> > best use of GitHub PR. > > > >> > > > > >> > Thoughts? > > > >> > > > > >> > > > > > > > > > > > > -- > > busbey > > > > - > > To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org > > For additional commands, e-mail: common-dev-h...@hadoop.apache.org > > > > >
Re: [DISCUSS] GitHub PRs without JIRA number
Thanks all for the discussion. I'm +1 for adding PR template and I wrote a patch long ago: https://issues.apache.org/jira/browse/HADOOP-15184 I'm interested in "test this", "retest this", etc. I'll file a jira for this feature. -Akira On Thu, Sep 5, 2019 at 4:05 AM Sean Busbey wrote: > We should add a Pull Request Template that specifically calls out the > expectation that folks need to have a JIRA associated with their PR > for it to get reviewed. Expectations around time to response and how > to go about getting attention when things lag would also be good to > include. (e.g. are folks expected to ping on the jira? are folks > expected to email a relevant *-dev list?) > > If anyone is interested in doing the work to make it so "test this" / > "retest this" / etc work, open a jira and I'll give you some pointers > of examples to go off of. We use a plugin to do this for yetus based > tests in some HBase repos. > > On Wed, Sep 4, 2019 at 1:59 PM Wei-Chiu Chuang > wrote: > > > > +general@ > > > > > > On Wed, Aug 28, 2019 at 6:42 AM Wei-Chiu Chuang > wrote: > > > > > I don't think our GitHub integration supports those commands. Ozone has > > > its own github integration that can test individual PRs though. > > > > > > > > > > > > On Tue, Aug 27, 2019 at 12:40 PM Iñigo Goiri > wrote: > > > > > >> I wouldn't go for #3 and always require a JIRA for a PR. > > >> > > >> In general, I think we should state the best practices for using > GitHub > > >> PRs. > > >> There were some guidelines but they were kind of open > > >> For example, adding always a link to the JIRA to the description. > > >> I think PRs can have a template as a start. > > >> > > >> The other thing I would do is to disable the automatic Jenkins > trigger. > > >> I've seen the "retest this" and others: > > >> > https://wiki.jenkins.io/display/JENKINS/GitHub+pull+request+builder+plugin > > >> https://github.com/jenkinsci/ghprb-plugin/blob/master/README.md > > >> > > >> > > >> > > >> On Tue, Aug 27, 2019 at 10:47 AM Wei-Chiu Chuang > > >> wrote: > > >> > > >> > Hi, > > >> > There are hundreds of GitHub PRs pending review. Many of them just > sit > > >> > there wasting Jenkins resources. > > >> > > > >> > I suggest: > > >> > (1) close PRs that went stale (i.e. doesn't compile). Or even close > PRs > > >> > that hasn't been reviewed for more than a year. > > >> > (1) close PRs that doesn't have a JIRA number. No one is going to > > >> review a > > >> > big PR that doesn't have a JIRA anyway. > > >> > (2) For PRs without JIRA number, file JIRAs for the PR on behalf of > the > > >> > reporter. > > >> > (3) For typo fixes, merge the PRs directly without a JIRA. IMO, > this is > > >> the > > >> > best use of GitHub PR. > > >> > > > >> > Thoughts? > > >> > > > >> > > > > > > > -- > busbey > > - > To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org > For additional commands, e-mail: common-dev-h...@hadoop.apache.org > >
Re: [DISCUSS] GitHub PRs without JIRA number
We should add a Pull Request Template that specifically calls out the expectation that folks need to have a JIRA associated with their PR for it to get reviewed. Expectations around time to response and how to go about getting attention when things lag would also be good to include. (e.g. are folks expected to ping on the jira? are folks expected to email a relevant *-dev list?) If anyone is interested in doing the work to make it so "test this" / "retest this" / etc work, open a jira and I'll give you some pointers of examples to go off of. We use a plugin to do this for yetus based tests in some HBase repos. On Wed, Sep 4, 2019 at 1:59 PM Wei-Chiu Chuang wrote: > > +general@ > > > On Wed, Aug 28, 2019 at 6:42 AM Wei-Chiu Chuang wrote: > > > I don't think our GitHub integration supports those commands. Ozone has > > its own github integration that can test individual PRs though. > > > > > > > > On Tue, Aug 27, 2019 at 12:40 PM Iñigo Goiri wrote: > > > >> I wouldn't go for #3 and always require a JIRA for a PR. > >> > >> In general, I think we should state the best practices for using GitHub > >> PRs. > >> There were some guidelines but they were kind of open > >> For example, adding always a link to the JIRA to the description. > >> I think PRs can have a template as a start. > >> > >> The other thing I would do is to disable the automatic Jenkins trigger. > >> I've seen the "retest this" and others: > >> https://wiki.jenkins.io/display/JENKINS/GitHub+pull+request+builder+plugin > >> https://github.com/jenkinsci/ghprb-plugin/blob/master/README.md > >> > >> > >> > >> On Tue, Aug 27, 2019 at 10:47 AM Wei-Chiu Chuang > >> wrote: > >> > >> > Hi, > >> > There are hundreds of GitHub PRs pending review. Many of them just sit > >> > there wasting Jenkins resources. > >> > > >> > I suggest: > >> > (1) close PRs that went stale (i.e. doesn't compile). Or even close PRs > >> > that hasn't been reviewed for more than a year. > >> > (1) close PRs that doesn't have a JIRA number. No one is going to > >> review a > >> > big PR that doesn't have a JIRA anyway. > >> > (2) For PRs without JIRA number, file JIRAs for the PR on behalf of the > >> > reporter. > >> > (3) For typo fixes, merge the PRs directly without a JIRA. IMO, this is > >> the > >> > best use of GitHub PR. > >> > > >> > Thoughts? > >> > > >> > > -- busbey - To unsubscribe, e-mail: general-unsubscr...@hadoop.apache.org For additional commands, e-mail: general-h...@hadoop.apache.org
Re: [DISCUSS] GitHub PRs without JIRA number
+general@ On Wed, Aug 28, 2019 at 6:42 AM Wei-Chiu Chuang wrote: > I don't think our GitHub integration supports those commands. Ozone has > its own github integration that can test individual PRs though. > > > > On Tue, Aug 27, 2019 at 12:40 PM Iñigo Goiri wrote: > >> I wouldn't go for #3 and always require a JIRA for a PR. >> >> In general, I think we should state the best practices for using GitHub >> PRs. >> There were some guidelines but they were kind of open >> For example, adding always a link to the JIRA to the description. >> I think PRs can have a template as a start. >> >> The other thing I would do is to disable the automatic Jenkins trigger. >> I've seen the "retest this" and others: >> https://wiki.jenkins.io/display/JENKINS/GitHub+pull+request+builder+plugin >> https://github.com/jenkinsci/ghprb-plugin/blob/master/README.md >> >> >> >> On Tue, Aug 27, 2019 at 10:47 AM Wei-Chiu Chuang >> wrote: >> >> > Hi, >> > There are hundreds of GitHub PRs pending review. Many of them just sit >> > there wasting Jenkins resources. >> > >> > I suggest: >> > (1) close PRs that went stale (i.e. doesn't compile). Or even close PRs >> > that hasn't been reviewed for more than a year. >> > (1) close PRs that doesn't have a JIRA number. No one is going to >> review a >> > big PR that doesn't have a JIRA anyway. >> > (2) For PRs without JIRA number, file JIRAs for the PR on behalf of the >> > reporter. >> > (3) For typo fixes, merge the PRs directly without a JIRA. IMO, this is >> the >> > best use of GitHub PR. >> > >> > Thoughts? >> > >> >
