I dug in and found the config. It's in the global plugin config, so it's shared across all the Apache projects. Not really easy to change, unfortunately.
On Fri, Feb 8, 2019 at 10:58 AM Fieck, Brennan <[email protected]> wrote: > > dangogh looked and couldn't find a place where that was configured, dunno if > anyone else would know > ________________________________________ > From: Rawlin Peters <[email protected]> > Sent: Friday, February 8, 2019 10:35 AM > To: [email protected] > Subject: [EXTERNAL] Re: How to Use Continuous Integration for Fun and > (Non-)Profit! > > Hey Chris, > > Thanks for the explanation. Would it be possible to include the secret > decoder ring in the "Can one of the admins verify this patch" comment? > That way we don't need to remember if it's "please test this" or "test > this please", etc. I can't think of any reason why we shouldn't > include the list of commands in that comment, since the commands are > already public knowledge. > > - Rawlin > > On Fri, Feb 8, 2019 at 10:22 AM Chris Lemmons <[email protected]> wrote: > > > > 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.
