You can do it one build if you just specify two executions for the failsafe plugin. Then you can configure different system variables for the executions.
Andreas Am Samstag, 28. März 2015 schrieb Tecno Brain : > Separate attract build from integration tests. > > In the integration test: > -Set up your system (cleanup, install) > - run with the flag disabled > - run again with the flag disabled > > I would use Jenkins build steps rather than maven profiles > On Mar 27, 2015 3:15 PM, "Stefan" <[email protected] <javascript:;>> > wrote: > > > Hi guys, > > > > I've been banging my head over the following problem lately and wasn't > > able to find a solution at all on the interwebs. > > > > So, here's some context. I'm working on multiple RESTful APIs within a > > microservices architecture. Some of these applications can form separate > > stand alone sub-systems, which can safely be deployed on secured > > environments with API security turned off. Or, they can be deployed as > > public services, where some actions need proper authorization - i.e. > > addition and deletion of content, cluster management, etc. > > > > I want to be able to run 2 sets of, basically acceptance tests, within > the > > build of each API. I need to start the APIs with different configurations > > and execute: > > > > 1. all tests against secured API > > 2. all tests - security tests against unsecured API > > > > The setup is also not trivial, as some of the APIs work with > > Solr/Cassandra/GraphDB, but at least it's the same for all tests and can > be > > reused. The only change between test runs would be a single JVM parameter > > which turns security on and off. > > > > Basically, I want to be able to execute the /pre-integration-test -> > > integration-tests -> post-integration-test -> verify/ lifecycle phases > > multiple times. > > > > At the moment the best option I can see is to create multiple profiles > and > > run the build multiple times. This has the obvious disadvantages of: > > > > 1. unnecessarily repackaging artifacts multiple times > > 2. can't run all tests with one command, which opens the door for > > errors on dev machines > > 3. Jenkins builds will become heavier and again, increased possibility > > of errors when configuring the jobs > > > > Do you have any better ideas? > > > > Thanks, > > Stefan > > > > -- > > Stefan Enev<[email protected] <javascript:;>> > > Technical Architect, Publishing Platform > > Ontotext AD > > > > >
