Some Slack discussion pointed out that we've got a bunch of contributors and a few committers that never got a rundown on how our CI system works. Here's a high-level overview:
Whenever someone opens a PR against the apache/trafficcontrol the PR builder on Apache Jenkins will try to build it. For security reasons, only people on a whitelist are automatically allowed to build. For folks not on the whitelist, asfgit will make a comment: "Can one of the admins verify this patch?" If you are a committer and you see that comment, it means Jenkins is asking if it's ok to run the test. You can take a quick gander at the code. You don't need to do a full code review, but just scan and make sure there's nothing obviously malicious in the PR. It's pretty unlikely, but it's why we have a committer review first. Assuming all is good, like it always is, you can reply: "ok to test" to mark the PR as acceptable for testing. "test this please" gets you a one-time test. And if the contributor is an ongoing community member, add them to the whitelist with "add to whitelist". This lets them build without having to wait for a committer each time. You can see the details in the description of the plugin here: https://builds.apache.org/view/S-Z/view/TrafficControl/job/trafficcontrol-PR/ And it's important that we get the PR Builder running on anything we want to merge because we want to ensure that we've got clean builds. As was pointed out, busted builds beget busted builds. If you're a committer and you're looking to merge, take a quick gander at the check mark next to the most recent commit. If it's missing, or an X, you probably want to dig into why. Seriously consider not merging until the build passes, because if the build frequently fails, folks tend to stop trusting it.
