https://bugzilla.wikimedia.org/show_bug.cgi?id=34617
--- Comment #10 from Krinkle <[email protected]> 2012-05-17 01:48:19 UTC --- Ideally we'd extend the test we already have instead of creating a new test. Instead of just checking out the target branch, applying the change and installing MediaWiki, it would also check out a selection of extensions. It's a little tricky though. The Jenkins job is monitoring all branches of mediawiki/core.git if a change is made to REL1_19, it checks out REL1_19, applies the change and runs the suite. If a change is made on master, it checkouts out master first etc. How do we deal with extensions? The script can quickly become very complex. We could make it so that it loops through the selected extensions, and if there is no branch in the extension by the same name, skip it. Also note that extensions have their own repository. So changes to extensions are not run through the test suite (yet). There's a few ways to go about this. Maybe it's obvious, but I'm not sure. == Re-use Jenkins "MediaWiki GIT Fetcher" job == * The job has an array of selected extensions that will be tested for (for now, we start with extensions deployed on WMF). Whenever the a build is triggered it starts as usual by updating the remote and switching to the correct branch and applying the change. We'd add to this that it will loop through the set of extensions and if it has an equally named branch, check that out into ./extensions and add it to a list for later (when creating LocalSettings.php). This way the installer will also take extension tables into account * Then we change the job configuration to also trigger on changes for any branches in the mediawiki/extensions/{in array}.git repositories (in addition to in mediawiki/core.git). If the extension change is on a branch that has no equally named branch in mediawiki/core.git then change is ignored and can't be tested. == Use wmf-branch == Alternatively we could take the simpler approach and keep the "MediaWiki GIT Fetcher" job exactly as it is. I don't know if it is running currently for wmf-branches or not (afaik it runs on ** all branches), but if not we'd make it so that it does. Maybe we need to add a call for it to initialize/update submodules. After that it should automatically install the extensions and run them as part of the test suite. Although this is a lot simpler and doesn't involve any branch magic-matching. The downside that it would only test things once we intend to update the submodule. I'd say we do both: * Make sure that any submodules are expanded. So that whenever a change is made to a wmf-branch, the test suite will run including extensions. Thus verifying that the to-be-merged change will work as expected on that wmf branch (i.e. not break core - and not break any deployed extensions). * Whenever a change is made to non-wmf branch: Include all selected extensions by installing them from the equally named branch in the relevant repositories. What'dya think? -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
