"multiwiki is only designed to diverge at a MediaWiki extension and config level"

Really?

We run multiple release branches in production, would it really be difficult to duplicate this in vagrant? Seems like it should be fairly easy to fix this but I may be missing something huge here.

@mmodell: It's probably not too difficult, but the obstacle as usual is Puppet's narrow concept of code reuse. The last time I tried implementing multiple release branches, I got dragged into a huge morass of refactoring how mw-extensions relate to their parent mw-core resource, for example. Probably the key here is to just get an agreement on how to proceed.

I think I could fix this if I had a better idea what you need to do specifically...

Should this be a separate, parallel core branch or you just need an easy way to switch back and forth between master and your feature branch?

Well, that would be great, this is a major blocker for us. I'm available to support in whatever way I can.

I think it needs to be a parallel checkout of mw-core, because currently (fundraising-REL1_23) our branch includes files which would be modified as a normal part of doing fundraising development, and I wouldn't want developers to have to stash those, and risk losing work. Interference in the other direction is an issue too--when I first implemented this the naive way, simply checking out the FR branch of core when the FR role is enabled, I was told it would be too annoying for mw-core developers who were dabbling in FR stuff, to have their master branch overwritten.

@awight: So, we should have the fr-branch checked out in an alternate location and either set up a separate virtual host listening on an alternate port or set up a way to switch the location of core based on a setting. It seems like it might be best to have an alternate port since that would be minimal interference with existing work and it would allow parallel access to both branches without having to reconfigure things.

Change 200335 had a related patch set uploaded (by 20after4):
Implement support for the src_dir argument in mediawiki::wiki

https://gerrit.wikimedia.org/r/200335

@awight:

try out the patch that I just submitted to gerrit ^

All you need to do is apply the patch to your mediawiki-vagrant repo, then check out your branch of mediawiki-core into /vagrant/mediawiki-fr/, then enable the new fundraising_wiki role.

This should be everything:

cd ~/src/mediawiki-vagrant
git fetch https://gerrit.wikimedia.org/r/mediawiki/vagrant refs/changes/35/200335/1 && git cherry-pick FETCH_HEAD
git clone https://gerrit.wikimedia.org/r/p/mediawiki/core.git mediawiki-fr
cd mediawiki-fr
git checkout fundraising/REL1_23
cd ..
vagrant roles enable fundraising_wiki
vagrant provision

At this point it runs your branch of the code, however, it doesn't find the requisite configurations on my machine, presumably because I have no idea what configs are necessary for your branch of the code. I'm hoping this works for you, if I've missed something please let me know.

This looks like a great start! A few things would still need to happen:

• /vagrant/mediawiki-fr checkout should be done by puppet, using a "branch" argument to the role::fundraising_wiki mediawiki::wiki.
• This new instance should depend on a few mediawiki extensions.
• Additional port forwarding should be set up by vagrant.

I think the mediawiki::wiki "include ::mediawiki" still needs to be expanded?

awight: additional port forwarding isn't needed - you simply make a wildcard host entry in your /etc/hosts file:

127.0.1.1 *.local.wmftest.net

Then you can use http://fundraising.wiki.local.wmftest.net:8080/ to access your wiki.

@awight: not sure what extensions you want, and I'm not sure what is the status of the old 'fundraising' role - everything breaks when I enable it... But the other issues are addressed and I think it's ready for you and your team to try it out, provide feedback, etc. And as @bd808 said in comments on gerrit, finishing this up would make a good hackathon project.

In T78739#1168771, @mmodell wrote:

awight: additional port forwarding isn't needed - you simply make a wildcard host entry in your /etc/hosts file:

127.0.1.1 *.local.wmftest.net

Then you can use http://fundraising.wiki.local.wmftest.net:8080/ to access your wiki.

This /etc/hosts hack is only needed for offline usage. The WMF DNS servers include the wildcard entry:

$ dig @ns0.wikimedia.org fundraising.local.wmftest.net

; <<>> DiG 9.8.3-P1 <<>> @ns0.wikimedia.org fundraising.local.wmftest.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32214
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;fundraising.local.wmftest.net.	IN	A

;; ANSWER SECTION:
fundraising.local.wmftest.net. 3600 IN	A	127.0.0.1

;; Query time: 104 msec
;; SERVER: 208.80.154.238#53(208.80.154.238)
;; WHEN: Fri Apr  3 09:17:04 2015
;; MSG SIZE  rcvd: 63

A small correction to the last comment:

This /etc/hosts hack is only needed for offline usage. The WMF DNS servers include the wildcard entry:

$ dig @ns0.wikimedia.org fundraising.local.wmftest.net

The hostname is actually fundraising.wiki.local.wmftest.net

MModell's patch is working well, thanks again!

Change 200335 merged by jenkins-bot:
Implement support for the src_dir argument in mediawiki::wiki

https://gerrit.wikimedia.org/r/200335

I merged the change. If you'd like I can add the relevant mediawiki extensions to the new fundraising_wiki puppet role in a separate patch. After that's done I think we can close this task, unless you can think of anything else that would help to make this feature convenient and useful for your team.

@awight: What do you think?