Wikimedia Release Engineering Team/Local Dev Sync/2020-02-27
Appearance
Agenda/Notes:
[edit]- 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
Previous action items
[edit]- [kosta] Docs docker in core on how to run unit tests, note that it's for temporary testing not long-term data storage, etc.
- Done 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
- Done Update the main (Docker?) dev page with our new solution (once it's merged) and figure out where the docker recipes should go
- Done 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
- Done Trying to get IDEs to test with k8s - Mukunda & Jeena
- [declined] Do something about the mediawiki-docker in github
Action items:
[edit]- 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