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 > _________________________________________ 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]
