Topic on Talk:Continuous integration/Flow

One thing I would very much like to have is an automated mechanism to update the labs cluster VM wikis reliably to some known version of MW for those configurations. Right now I think it would be best to update those nightly from Jenkins rather than after each commit, or whatever. (I've discussed this with Antoine somewhat)

Ultimately this serves two purposes: for one thing, it offers a chance to bring in the global testing community at will for ongoing testing of new features. For another thing, in the longer term I would like to add some builds downhill from the deploy-to-labs-cluster builds that would run a suite of cross-browser UI tests against the labs cluster environments nightly.

I've put up a QA/testing status page to track this and other items.

I like this idea a lot!
I thought about proposing an additional check in this Jenkins hook to also check the codereview status of the revisions. So that it would update the wikis to the "latest reviewed revision that passes the unit tests". However after the Git migration, mediawiki-core/master wiill only contain reviewed commits anyway, so such check is no longer necessary. Nice :)

Lab's "beta" project (renamed from "deployment-prep") was originally meant to show the next release, not alpha or trunk ("master" or "svn trunk").

I don't think that "beta" should be running on trunk. However it should be relatively easy to set up another labs' project just like "beta" (e.g. named "mw-alpha") which would indeed run on trunk.

Both "mw-alpha" and "mw-beta" would be automatically updated by this Jenkins hook.

Which reminds me, right now we don't have a project for REL1_19 in Jenkins (we should!), previously when we still used phpUnderControl we did monitor the release branches.

My purpose here is to have a reliable world-shareable test environment, running the latest reliable MediaWiki code, in test wikis configured closely to production.

A reliable test environment is important for almost every aspect of the QA/testing work I want to accomplish.

Krinkle wrote:

Which reminds me, right now we don't have a project for REL1_19 in Jenkins (we should!), previously when we still used phpUnderControl we did monitor the release branches.

I will have to test how Gerrit git plugin works out with branch. IIRC, it just listen for any change proposal made in gerrit, checkout the branch, apply patch then run tests. So we most probably only need one git fetching job to handle all branches.