Wikimedia Release Engineering Team/Local Dev Sync/2020-05-21

Discussion edit

  • Combine mediawiki-docker-dev / mediawiki-docker efforts? (???)
    • Adam: Decided to rewrite how mediawiki-docker-dev worked on Tuesday
      • More flexible roles, etc.
      • On Wednesday got an e-mail about evaluating developer environments, tried real hard to make mw-docker-dev work...
      • Tried out mw-docker stuff and mwcli stuff.
      • Think maybe mwcli stuff could take over mw-docker-dev, but there are good learnings from mw-docker-dev that could feed in.
    • Adam:  My dream is that there's a CLI that lets you interact with these docker-compose elements in various repos and just pulls it together.
    • Jeena: Think people will be resistant to docker-compose files in other repos?
    • Adam: I don't think we should be too worried.  There's some flexibility.
    • James: Thoughts:
      • Average mw extension is pretty boring and samey.  Maybe we have a fallback setting where we don't need to add files.
      • The other side of that is that fanning out to individual repos gives those repos control, which is both good and bad.  Hard to tie things together for CI purposes.
      • Say Parsoid changes its entrypoint - they then need to change their docker-compose fragment...
      • Potentially an inversion of dependency principle.
      • The other benefit of centralizing everything is that it's easier to land a change of configuration in a single go.
    • Adam: Had another thought - if you want to use multiple docker-compose files together, they need to be the same version.
      • James: Naming convention for files?
    • Brennen, Mukunda: What if most files for docker-compose live in the cli and overrides are in the repo

This is a cool idea

    • James: We've thought of docker as a lightweight solution where you don't have to stand up things like elastic search and redis. Now we're talking about doing that. I would love to combine efforts, but don't want mediawiki-docker to become bloated and slow, or taking over mediawiki-docker-dev and changing it for the worse
    • Mukunda: so essentially the cli would have a list of places to look for compose files and you can add more to it by running a command? and each repo could have a hook that runs on install if you want to do fancy stuff
    • Adam:  yus, you need something like that, and generic other scripts to help you do things,
    • James: Also please tear down script entry points, not just install ones.
    • Adam: Currently first I "just" need to implement what's happening in docker-dev in mediawiki-cli, then we could see what we think about it
    • [demo]
      • Side question: Could install.php have an option to not create LocalSettings.php?
      • Side note: We should make sure to create "official" images where needed

Mukunda: it would be cool if there are directories which define sets of commands and services, that directory could exist in a repo full of other commands or in a repo along with the mediawiki extension so essentially the cli needs a good discovery mechanism Adam: Yes Brennen: We should have a task to evaluate this Jeena: I don't think we should get bogged down in trying to determine if something is good enough and never do anything Adam: I could add it to mw-cli behind a feature flag and you could try it Brennen: The idea of the cli is to be able to put different things behind subcommands Mukunda: Plan to mock it out in stubs and maybe we can fill out some stuff

Action items: edit

Previous action items edit