Goal: provides provide additional quality checks on top of the Hadoop Yetus checks, including all docker based acceptance test suite.

...

Note: everything here is just experimental which can help to decide which method can be the best for the future. This wiki page summarizes the current state/experiences to be base of a discussion.

TLDR;

1.  You can create pull request to apache hadoop repository
2.  You need to add the ozone label to check it with Jenkins.
3.  It will be checked by this Jenkins: https://ci.anzix.net/job/ozone
4.  The result will be visible as github status checks:
5.  See the examples here: https://github.com/apache/hadoop/pull/464
6.  The checks are additional checks, not replacement of the Yetus checks. AW and others are working on the PR support of Yetus.

The background

There are two main methods to check github PR-s in Jenkins:

1.   Github Branch source plugin + Pipeline: multibranch plugin
2.   Github Pull Request Builder plugin

Github Branch source plugin

This is more easy to use and more simple.

...

Every PR will have a separated job and the incremental builds are easily followed.

Github Pull Request Builder plugin

This is a more advanced plugin but not for the multi-branch pipline just for the simple pipeline. It is just one job which can build all PRs (and branches), but there is no separated job instances for the separated PRs.

...

(see this thread: https://mail-archives.apache.org/mod_mbox/www-builds/201901.mbox/browser if you interested why is it important to trigger build only for the whitelisted users/organizations)

Which approach is the best

1. The first approach is more easy to use and more simple
   
   
2. The second approach is more safe (advanced user whitelist settings)
   
   
3. The first approach can't work with hadoop/ozone where there could be multiple Jenkinsfile on trunk. There is no easy way to filter the ozone only PRs. The first approach doesn't support label based filtering.
   
   
4. The second approach can't work on builds.apache.org as of now. I need to request a new jenkins plugin (will do).
   
   

Current problems (Update1)

Summary: The second approach seems to be more better for Ozone (as of now)

...

Workarounds: as of now the experimental Jenkinsjob uses my credentials and started from a linode cloud server (I got free 50$ at ApacheCon, which is used here to support apache development). I will request the installation of the required notify plugin from INFRA to migrate it to the builds.apache.org. Until that I will try to find a way to publish the admin password (it's an empty box, I have no personal info there, happy to share)

Update2:

1. I don't like the Github Pull request builder any more. It adds random comments to the github if the author is not white listed.I think the right approach is to use something like prow: an external tool which can trigger the build and handle the comment based workflows. I am investigating the possible tools, and in the meantime I use a simple script to trigger the PRs (if they are marked with ozone labels).
2. Ozone checks still run on an experimental location (ci.anzix.net) because I need a lot of experiments and testing and we have not enough resource at builds.apache.org. Jenkinsfile is committed to the hadoop-ozone and the jobs will be migrated t builds.apache.org after stabilization.

Future directions

Kubernetes (and other CNCF projects) use prow to manage the CI workflow.

...