Wikimedia Release Engineering Team/Local Dev Sync/2020-02-27

Agenda/Notes:

 * TMH
 * Originally was a goal for local-charts
 * Might be a good way of thinking about the edges of where docker-compose stuff are
 * Discussion around building a new docker image or having a users write a dockerfile


 * missing some php modules
 * php-ast
 * phan
 * xhprof
 * https://gerrit.wikimedia.org/r/c/releng/dev-images/+/574983
 * ^ needs review
 * https://gerrit.wikimedia.org/r/c/releng/dev-images/+/511063 old patch with relevant comments
 * whatever needed to reproduce a CI build
 * mw CLI
 * brennen: what about keeping the top level available for other things?
 * James: worried about this becoming complicated
 * Have decided we won't be supporting installing extensions for the community via composer, so this part might not be achieveable?
 * Kosta: talking through someone getting set up and some things are scary/too much for a new person, which is the inspiration fo the CLI/wrapper script
 * For extensions, they would have to work out of the box to be able to add them to the wrapper, like skins
 * Mukunda: could have a questionnaire (for popular extensions) that gets the needed variables and does the configuration
 * there should be something that specifies the schema for each extension
 * Kosta: things should be added to the maintenance script in order to set up for extensions
 * James: There is scripting for extensions for db schema changes
 * but look at issues with vagrant
 * Jeena: Let's avoid using the dev env as a dependency management solution
 * Brennen: Yeah, but hopefully we can use the env to do the most basic parts
 * Kosta: Developers.md is pretty long. if there is a wrapper script, it should hopefully reduce the length of the developers.md
 * People shouldn't have to copy things from the developers.md and paste them somewhere to get the env running
 * James: agreement that we do want some kind of wrapper script for simple things
 * Brennen: need to sign and provide hashes for the binary we ask people to dl
 * +1
 * Kostsa: is the utility just focused on the docker stack or should it allow for sub-commands?
 * Brennen: think it should allow for sub commands
 * +1 Jeena
 * James: would be nice to be able to re-use mw if not using docker in the future
 * Mukunda: mediawiki.dev top-level domain is available :)
 * James: or media.wiki
 * php storm tests
 * Jeena: Some background - looked into running running unit tests [against local-charts?].  Worked in VSCode, not so much PhpStorm.
 * TODO: Kosta to write to JetBrains
 * see also https://youtrack.jetbrains.com/issues?q=kubectl

Previous action items

 * [kosta] Docs docker in core on how to run unit tests, note that it's for temporary testing not long-term data storage, etc.
 * ✅ also added notes about running selenium and api-testing tests
 * File task for cleaning up maintenance/dev scripts
 * Docs for what happens when there is a new version of the docker image
 * ✅ Update the main (Docker?) dev page with our new solution (once it's merged) and figure out where the docker recipes should go
 * ✅ Phab component for tracking changes, update DEVELOPERS.md with reference to it and #mediawiki support channel - Using existing mediawiki-docker tag
 * [kosta] updated the docs for that
 * ✅ Trying to get IDEs to test with k8s - Mukunda & Jeena
 * [declined] Do something about the mediawiki-docker in github

Action items:

 * Docs for what happens when there is a new version of the docker image
 * File task for cleaning up maintenance/dev scripts
 * Make the wrapper script
 * Shorten Developers.md with wrapper script
 * Adding various needed packages to docker image for mw
 * TMH follow up
 * Brennen to plead for assistance from James if necessary
 * request k8s support from jetbrainz