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 <aajis...@apache.org> 于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 <bus...@cloudera.com.invalid> > 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 > > <weic...@cloudera.com.invalid> wrote: > > > > > > +general@ > > > > > > > > > On Wed, Aug 28, 2019 at 6:42 AM Wei-Chiu Chuang <weic...@apache.org> > > 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 <elgo...@gmail.com> > > 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 > > > > >
