I'm +1. If nothing else, it doesn't add any dependencies to actually *running* ATC or CIAB, and JUnit files are technically human-readable (though I certainly wouldn't love doing that often)> ________________________________________ From: Robert Butts <[email protected]> Sent: Thursday, January 24, 2019 2:35 PM To: [email protected] Subject: [EXTERNAL] CiaB Test Compose Outputting JUnit?
Does anyone object to making the cdn-in-a-box test compose files (e.g. https://github.com/apache/trafficcontrol/blob/master/infrastructure/cdn-in-a-box/docker-compose.traffic-ops-test.yml) output JUnit format? I made an internal fork to do that for `docker-compose.traffic-ops-test.yml` as well as complete Dockerfiles+Compose for the TM, Portal, and Router tests. At the time, I didn't OSS them, because I thought we shouldn't impose JUnit on TC. But in retrospect, it limits our contributions to TC for no good reason. Further, TC uses the Apache Jenkins server, which expects JUnit. So I'm not seeing a reason not to standardize all of our docker-compose test infrastructure around JUnit. Note I'm only talking about the `docker-compose` infrastructure to run tests, not the tests themselves. The tests themselves inside each project won't change -- the Router already outputs JUnit, TO and TM output Go test format, etc. Does anyone object to that? Are we ok with adding `docker-compose` infrastructure for running TO API, TO Unit, Monitor, Router, and Portal tests outputting JUnit?
