Providing PR/Patch build

[Evans Ye <ev...@apache.org>]

Hi all,

Recently I'm surveying the way to provide pr/patch build for our project.
That way we can largely reduce the time to review patches.

I'm still not totally understanding how it works, but either way seems to
need proper credentials beforehand. For pr build, we need apache github
credentials. For patch build, we need JIRA credentials.

After a bit more survey, I found most of the projects are leveraging
builds.apache.org, which already have credentials properly configured.
(BTW, apache infra indeed did a great job!)

For example:
https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HDFS-Build/

Therefore, I'm thinking that maybe we can split out one of our build slave
under ci.apache.org to be builds.apache.org's build slave, which will be
responsible for pr/patch build, or more.

I still need some time to understand the whole things, but I'd like to pop
up this for discussion first. Any thoughts?

Re: Providing PR/Patch build

[Roman Shaposhnik <ro...@shaposhnik.org>]

On Sat, Mar 4, 2017 at 5:04 AM, Evans Ye <ev...@apache.org> wrote:
> Hi all,
>
> Recently I'm surveying the way to provide pr/patch build for our project.
> That way we can largely reduce the time to review patches.

As a matter of fact, long time ago we had something like this. For a project
like Bigtop, though, the biggest question was on what set of architectures
do we test patches before we decide they are OK.

> I'm still not totally understanding how it works, but either way seems to
> need proper credentials beforehand. For pr build, we need apache github
> credentials. For patch build, we need JIRA credentials.
>
> After a bit more survey, I found most of the projects are leveraging
> builds.apache.org, which already have credentials properly configured.
> (BTW, apache infra indeed did a great job!)
>
> For example:
> https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HDFS-Build/
>
> Therefore, I'm thinking that maybe we can split out one of our build slave
> under ci.apache.org to be builds.apache.org's build slave, which will be
> responsible for pr/patch build, or more.

I don't think you can do that. Slaves are slave and they belong to a
given master.

> I still need some time to understand the whole things, but I'd like to pop
> up this for discussion first. Any thoughts?

I think the easiest would be to create either a dummy GH user or a
dummy ASF JIRA
user and manage the secret on our side (ci.bigtop.apache.org)

Thanks,
Roman.