works for me On Thu, Jan 24, 2019 at 4:13 PM Fieck, Brennan <[email protected]> wrote:
> 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? >
