Most Zuul tests are limited to a whitelisted set of Gerrit users to prevent a user from uploading malicious code as a patchset and have it executed on the continuous integration servers; only tests not involving code execution (such as basic linting) are run for everyone else. Jenkins-bot differentiates between the two type of tests by giving
Not being on the whitelist means that unit test failures or code style issues only get caught when a more privileged user tries to test or merge the patch, so the patch author's time is wasted on waiting for an extra code review cycle even though the issues with their patch could be easily detected by a machine without causing delay. (To some extent this can be mitigated by running the tests locally but that's not always easy to do.) Being on the list does not require a high level of trust - just that they're not malicious. If you are preparing for a development-focused event such as a hackathon, please add participants beforehand. The whitelist is in layout.yaml (there are actually two instances of it in the file, users need to be added to both), just add the primary Gerrit email address of the user to the list. An example patchset doing that is Gerrit change 353708.
If you are on the whitelist you can force Zuul to run all tests on a patchset by adding a comment containing only the word
recheck in Gerrit.