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

Goal: max it easier to contribute for newbies and external contributors (but use the existing apache)

Non-goal: avoid/remove Yetus checks

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: http://88.80.190.176:8080/job/ozone-pr/
  4.  The result will be visible as github status checks:
  5.  See the examples here: https://github.com/apache/hadoop/pull/464
  6.  You can rerun the tests with adding a comment: rerun test
  7.  The checks are additional checks, not replacement of the Yetus checks. AW and others are working on the PR support of Yetus.
  8.  As of now I both upload the patch to the JIRA (to get yetus results) and push as PR to the github (which provides more strict checks.

The story

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.

As an example for these kind of job, check this one: https://builds.apache.org/job/logging-log4net/ You can see that there are two tabs. The first includes all the branches and the second the active pull requests.

To work with it you need to commit a Jenkinsfile (we have one since HDDS-965) and the Jenkins can create jobs magically for PRs and/or branches based on patterns.

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.

It's more flexible: we can define github labels to exclude/include and we can define the users.

(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

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

  1. The two approaches requires different github notifier plugin (I prefer to attach the results of the builds as github 'status' objects). The notifier plugin of the second approach is not yet installed on builds.apache.org
  2. There is no clean way to use a service user. The service user needs a pull privilege which can be assigned only to real people according to the apache policies. (See this issue for more information: https://issues.apache.org/jira/browse/INFRA-17449)

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)

Future directions

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

It's an intelligent (pluggable) github PR bot + kubernetes job scheduler. The bot itself can be managed by /commands which are added to the PRs as comments.

As we have no public k8s server to test Ozone, the prow can't be used for us, but the approach could work. We may need some simple script which can do simple things on the PRs based on the current status or comments:

For example