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 req
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:
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/chan
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 t
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 selec
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 sho
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
+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
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 bes
On Tue, Aug 27, 2019 at 6:47 PM 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 th
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.
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 go
12 matches
Mail list logo
