*Providing credentials * I went through the two options mentioned above. ( and tested them by implementing). It would be more convenient and a lot cleaner to use System properties.
As Amila has mentioned we can provide the myProxy credentials and the Certs as System properties. If the myproxy properties are provided, GRAM/GSISSH tests will be run.( currently we are targeting Jenkins) Any suggestions? *Tests memory requirement* The current build requires a lot of memory to run. I tested the integration tests using parallel testing( same JVM different threads) and Forking( different processes) and both required less memory. In parallel testing, there can be a race condition issue. Any opinions on using these? ( out of curiosity, since it's not a huge issue) On Wed, Jan 8, 2014 at 7:49 PM, Amila Jayasekara <[email protected]>wrote: > Well... I am not sure about this. > Let me share some of my experiences with maven profiles. > > Developers usually use "mvn clean install". Further we usually dont > activate profile building before committing some code change to svn. > So if we configure Jenkins with a profile, the result will be frequent > build breaks. > > Also profiles will get outdated very soon. > > Result of all these is inconsistent distributions. > > Also if developers need to run profile build before each commit why not > run integration tests in the default build ? > > My suggestion is to get certificate path, myproxy credentials as Java > system properties (i.e. "mvn clean install > -Dmyproxy.certpath=/Users/thejaka/certificates -Dmyproxy.user=xxx > -Dmyproxy.password=yyy"). If those parameters are not specified run default > integration tests. If those parameters are specified run Gram, GSISSH etc > ... tests also. > > Just my thought. But I am open to try out undermentioned strategy and see > how it progress. > > Thanks > Thejaka Amila > > > On Wed, Jan 8, 2014 at 3:24 PM, Suresh Marru <[email protected]> wrote: > >> On Jan 8, 2014, at 2:44 PM, Raminder Singh <[email protected]> >> wrote: >> >> > I want to suggest that we add integration tests (needs configurations) >> to a separate maven profile named integration-test or developer.We can add >> all the integration tests to the new maven profile and make it a good >> practice for developers to run those before every commit. This can help >> Airavata to have stable Jenkins build. Jenkins will be running all the unit >> test cases and other sanity testing of the build system. Integration test >> profile will require few configuration steps, like to setup certificates >> and credentials and we can add developer instructions. >> >> A big + 1 for having multiple profiles (with default being minimal) and >> having all these goals as separate jenkins configurations with appropriate >> test frequency and blame settings. >> >> Suresh >> >> >> > >> > WDYT? >> > Raminder >> > >> > On Jan 2, 2014, at 4:48 PM, Amila Jayasekara <[email protected]> >> wrote: >> > >> >> One possibility is to add them to svn and refer from svn. But I am not >> sure whether this will work. >> >> >> >> Thanks >> >> Amila >> >> >> >> >> >> On Thu, Jan 2, 2014 at 3:29 PM, Sachith Withana <[email protected]> >> wrote: >> >> Thanks Amila. >> >> >> >> That's good. How can we configure the certificates? Only the admin can >> do that right? >> >> >> >> >> >> On Thu, Jan 2, 2014 at 3:26 PM, Amila Jayasekara < >> [email protected]> wrote: >> >> Hi Sachith, >> >> >> >> One way is to pass myproxy credentials as system properties Java VM >> (i.e. like -Dmyproxy.user=xxx -Dmyproxy.password=yyyy). This we have to do >> in the Jenkins build configurations. Further only admin will be able to >> access jenkins configurations, therefore I believe my proxy credentials >> will stay safe. >> >> >> >> Thanks >> >> Thejaka Amila >> >> >> >> >> >> On Thu, Jan 2, 2014 at 2:12 PM, Sachith Withana <[email protected]> >> wrote: >> >> Hi all, >> >> >> >> How can I allow the Jenkins build to test the integration tests for >> the providers since the credentials and the certificates are needed? >> >> >> >> -- >> >> Thanks, >> >> Sachith Withana >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> Thanks, >> >> Sachith Withana >> >> >> >> >> > >> >> > -- Thanks, Sachith Withana
