Hi Darius, In the approach of having all the release tests(of trunk and all the bundled modules) at one place, in a new release test maven project, the life cycle would be as follows
- We start with a new release-test maven project(1.0-SNAPSHOT) holding all the release tests of trunk and the bundled modules. Say, 1.9-SNAPSHOT and the HTM From Entry 1.7.3-SNAPSHOT, Form Entry 1.2.1-SNAPSHOT. - When 1.9 is released with bundled modules HTML Form Entry 1.7.3 and Form Entry 1.2.1, we'll branch our release-test maven project (say 1.0.1-SNAPSHOT) and the release trunk would be at (1.1-SNAPSHOT). - If we have some defects which are fixed in 1.7.3.1 then the corresponding release tests can be written in release-tests branch(1.0.1-SNAPSHOT). If we release HFE 1.7.4 released then we need to write the release tests in the release-tests trunk (1.1-SNAPSHOT) - Say because of any major refactoring the HFE 1.7.4 is unstable, we can send the previous stable version of HFE as the parameter for the release-tests trunk. *Problems:* - We can't randomly test with the different OpenMRS versions and the modules. In the above said approach we'll have release-test Trunk which have release tests for all the latest snapshot versions. Ex: OpenMRS 1.10-SNAPSHOT, HFE 1.7.4-SNAPSHOT, FE 1.2.2-SNAPSHOT . And the branches will always have the release tests for the released versions Ex: OpenMRS 1.9, HFE 1.7.3 and FE 1.2.1. We *can't* test 1.10-SNAPSHOT with HFE 1.7.3 and FE 1.2.1. In the other approach of having release tests (maven module) inside each of the OpenMRS trunk (1.9-SNAPSHOT) and the bundled modules, the life cycle would be as follows. - As we have all the release tests in different places(trunk and the bundled modules), we need to run all these tests in a common place. - So, we'll create a new maven project say release-test which will not have any logic except the parameterized dependencies to the trunk and the bundled modules. - This release-test project will copy all the release tests(from trunk and the required bundled modules) to one place and execute them. - As release tests are inside the corresponding projects (1.9-SNAPSHOT, HFE1.7.4-SNAPSHOT etc,) and parameterized we will *not *have any problems of running the different OpenMRS versions with different set of bundled modules. *Problems:* - Each of the release test modules in trunk and the bundled modules should follow the same package structure, else we can't copy the tests in correct places. - There might be problem cases where we might have name space problems where the bundled modules might have conflicting names for the stories(very rare scenario) - I tried creating this new maven project with appropriate dependencies and tried to run the downloaded release-test artifacts. But didn't had enough luck in executing them, as jbehave expects the tests to be in the source packages. PS: If you think email is not intuitive for this kind of discussion we can discuss the same during the implementers meet! :). If its too late then we can have a skype chat! On Sat, Oct 1, 2011 at 12:09 AM, Darius Jazayeri <[email protected]>wrote: > Hi Kishore, > > I thought the tricky point was figuring out which combination of things to > run. For example we'd keep a release-test line for each of our supported > OpenMRS versions: > * /release-tests/1.9.x > * /release-tests/1.8.x > * /release-tests/1.7.x (not really, because this isn't mavenized) > > Each of these would include a SNAPSHOT of the OpenMRS release branch (e.g. > 1.9.x) and specific versions of all bundled modules (e.g. HTML Form Entry > 1.7.3). Good: every time we backport a fix we re-test against all bundled > modules. Bad: we don't test against later module releases. (E.g. if we > bundled HFE 1.7.3, and we later release HFE 1.7.4, this newer version > doesn't get retested on every commit to 1.9.x.) > > Then I assume we'd have a /release-tests/trunk which would include a > SHAPSHOT of OpenMRS trunk. Would that include a SNAPSHOT of each bundled > module? (The downside of that is if you do a big refactoring in a module > between releases, leaving its trunk in a broken state, we'll get lots of > errors here.) Or would we include the latest-stable versions of bundled > modules? (If so, how do we do that?) > > Or are you suggesting something completely different, and saying we would > have a list of OpenMRS versions, and a list of module versions, and test all > combinations? > > -Darius > > > On Fri, Sep 30, 2011 at 7:34 AM, Burke Mamlin <[email protected]>wrote: > >> We would love to get continuous integration working on bundles. Your >> suggestion sounds like a very reasonable approach and similar to what we had >> pictured. If I'm following you correctly, the "release-tests" module would >> bring together trunk + bundled modules and perform both unit tests & >> integration testing on an instance of OpenMRS containing the bundled >> modules, while the unit & web app tests could still be created & kept in the >> appropriate places (trunk tests in trunk & module-specific tests with the >> module code)… that sounds great! >> >> We would want to structure the release-tests in a way that allowed for >> testing of multiple bundles – i.e., various versions of OpenMRS with >> differing sets & versions of modules – e.g., release-tests/1.9/ would have >> OpenMRS 1.9 + bundled modules, while /release-tests/1.9+sync/ includes the >> sync module. >> >> Cheers, >> >> -Burke >> >> >> On Fri, Sep 30, 2011 at 8:59 AM, Yekkanti Kishore Kumar < >> [email protected]> wrote: >> >>> Hi, >>> In order to automate our release tests to reap maximum benefits, we >>> wanted to run these tests constantly against the OpenMRS core versions and >>> their corresponding bundled modules. >>> >>> Ex: Say currently 1.9-SNAPSHOT holds release tests (currently we have >>> release tests in webapp-testing branch. We need to merge this with trunk) >>> and correspondingly any modules formentry1.1, htmlformentry1.2 have some >>> release tests. We need to run all of these release tests in a single >>> environment to detect any failures. >>> >>> *Current Situation: * >>> >>> - We have pipe lines for Trunk and couple of mavenized bundled >>> modules. >>> - All of these pipelines will run the tests in isolation. >>> - Bundled modules will not run there tests on the latest and greatest >>> trunk code. >>> - We don't have any release tests in the bundled modules but we are >>> aiming to introduce some. >>> - We have a separate branch * * webapp-testing which has the logic >>> for running the release tests and we are planning to merge the >>> webapp-testing branch to trunk >>> >>> *Proposed Solution:* >>> Considering we have merged the webapp-testing branch to trunk(so that >>> we'll have the release tests in the trunk) and all the required bundled >>> modules have the release tests we are trying to do the following. >>> >>> - Created a new maven module "release-tests" which have dependencies >>> on the core openmrs version and the bundled modules (all the versions are >>> parameterized) >>> - We'll download and copy the *release tests*(jbehave tests) from the >>> trunk and all the corresponding bundled modules(this would not be a >>> problem >>> as we have these dependencies already established) into >>> this(release-testing) maven module during generate source phase >>> - Run the release tests. >>> - As all the versions are parameterized we can fetch and run the >>> release tests of the specified versions of core or any of the bundled >>> modules. >>> >>> Can you guys think of any other easy approach to achieve the same. >>> >>> -- >>> Regards, >>> Kishore Kumar Yekkanti. >>> ------------------------------ >>> Click here to >>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >>> OpenMRS Developers' mailing list >> >> >> ------------------------------ >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> > > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > -- Regards, Kishore Kumar Yekkanti. _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
