Wikimedia Release Engineering Team/Local Dev Sync/2020-05-21
Appearance
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
- Adam: Decided to rewrite how mediawiki-docker-dev worked on Tuesday
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]- Adam: mock-up/outline docker-dev in mw-cli
- Adam: Write a ticket for releng to evaluate what is currenlty in v1 branch of mediawiki-docker-dev (for what? CI?)
- Mukunda: Write out a ticket tree of things we want? (!?)
Previous action items
[edit]- Jeena & Brennen to hack on TMH stuff during today's EngProd hackathon.
- Re: Docker image stats - James says this can maybe be pulled out of Hue.