A follow up here, after investigating these days, I tound that it is hard to trigger a build from the outside by another jenkins job, which is the old way we have done for PreCommit-Admin and PreCommit-HBase-Build job. The problem is that we need to simulate the gituhb webhook API, and also we need some credentials, which are not controlled by us.
So now, I just changed the HBase-PreCommit-GitHub-PR to scan periodically(every 10 minutes). The GitHub Branch Source plugin will try to skip triggering builds for unchanged PRs, which is good. The only problem is that, a PR will be considered as changed even if it is base branch is changed. For example, you create a PR which wants to merge a commit to the master branch, and if we push some new commits to master, then the scan job will consider your PR is changed, although you haven't done anything to the PR. But I think this is acceptable. In general, we 'should' re-run the pre commit check if the base branch is changed, before merging the commits back. This is also a good reason for us to close the stale PRs. Reply here if you have any questions. Thanks. Sean Busbey <[email protected]> 于2019年7月15日周一 下午9:01写道： > Also just to set expectations, the PR checking job might still give > you feedback occasionally because it will evaluate ALL open PRs any > time a committer goes to the build job and tells it to do a scan. > > I *think* the feedback it gives when it runs will still be as accurate > as normal. > > On Mon, Jul 15, 2019 at 2:25 AM 张铎(Duo Zhang) <[email protected]> > wrote: > > > > The jenkins job can not receive new builds event after July 10 > > > > https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/indexing/events > > > > Filed https://issues.apache.org/jira/browse/INFRA-18748 for this. > > > > Please consider using the old 'Submit Patch' way to run pre commit. > > > > Sorry about this. >
