Let's discuss at the meeting. -Darius
On Sun, Oct 2, 2011 at 7:57 AM, Yekkanti Kishore Kumar < [email protected]> wrote: > 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. > ------------------------------ > 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]
