Title | Reference | Author | Source Branch | Dest Branch | |
---|---|---|---|---|---|
[docker] add shellbox support | repos/releng/cli!138 | addshore | shellbox | main |
Details
Event Timeline
I had a quick look at this today.
There are pre built images that we could use https://www.mediawiki.org/wiki/Shellbox#Pre-built_containers
However these images each only have a subset of the total libraries needed for mediawiki usecases https://docker-registry.wikimedia.org/wikimedia/mediawiki-libs-shellbox/tags/
This would mean for a "full" set of shellboxes for local development we would actually need 5 services
Perhaps this is fine, though it doesn't scream amazing developer experience.
These types of image are all defined in https://gerrit.wikimedia.org/g/mediawiki/libs/Shellbox/+/3603c6a89d92b0f74d7baaefc5b53821f967fc43/.pipeline/config.yaml
We could also define an image to build that would have ALL of the needed libraries for development.
This could either be done in blubber, or done in dev images.
(I would leave toward blubber so this stays in sync with production).
OR I just implement the large number of shellbox services..?
Currently the help text for the mwdd / docker command in mwcli looks like this:
$ mw docker help The MediaWiki-Docker-Dev like development environment (alias: dev) Usage: mw docker [command] Aliases: docker, dev Available Commands: adminer adminer service custom custom service destroy Destroy all the containers docker-compose elasticsearch elasticsearch service env Interact with the environment variables eventlogging eventlogging service graphite graphite service hosts Interact with your system hosts file mailhog mailhog service mediawiki MediaWiki service memcached memcached service mysql mysql service mysql-replica mysql-replica service phpmyadmin phpmyadmin service postgres postgres service redis redis service resume Resume the Default containers suspend Suspend the Default containers where States the working directory for the environment Global Flags: --help help for this command --no-interaction Do not ask any interactive questions --verbosity int verbosity level (1-2) (default 1) Use "mw docker [command] --help" for more information about a command.
If we were to add 5 new services to this list, it could get quite messy
$ mw docker help The MediaWiki-Docker-Dev like development environment (alias: dev) Usage: mw docker [command] Aliases: docker, dev Available Commands: adminer adminer service custom custom service destroy Destroy all the containers docker-compose elasticsearch elasticsearch service env Interact with the environment variables eventlogging eventlogging service graphite graphite service hosts Interact with your system hosts file mailhog mailhog service mediawiki MediaWiki service memcached memcached service mysql mysql service mysql-replica mysql-replica service phpmyadmin phpmyadmin service postgres postgres service redis redis service resume Resume the Default containers shellbox-media shellbox-php-rpc shellbox-score shellbox-syntaxhighlight shellbox-timeline suspend Suspend the Default containers where States the working directory for the environment Global Flags: --help help for this command --no-interaction Do not ask any interactive questions --verbosity int verbosity level (1-2) (default 1) Use "mw docker [command] --help" for more information about a command.
Another alternative could be that we push some services down into groupings, such as shellbox, persistence, and stuff like that?
OR, only do this for shellbox? :/
It seems better to use the prebuilt images rather than have to maintain a new combined image. Thinking "out loud" - it seems a common use case for this would be for testing existing services, where you would not need (or perhaps want) all of those running at the same time. If, for example, you were testing some new functionality that relies on syntaxhighlight, you would only need to instantiate that shellbox service. It is already the case that you would start up your mediawiki service and your mysql service separately. As long as the list of services doesn't get too overwhelming, that would not be a problem. At the point that the number of services becomes overwhelming, I guess you could consider some layer of configurability on top of the services to bring up a set together for your desired environment. I do agree that creating groupings of services would help the list appear less overwhelming.
Note that https://www.mediawiki.org/wiki/Shellbox#MediaWiki_configuration indicates that there is a single shellbox URL, but that was deprecated in MW 1.37 in favor of
$wgShellboxUrls, so pointing to a different container for each shellbox service should be doable.
The other super important use case that I think is important is for development and testing of new shellbox services. So, it would be good to have a recipe for building a new shellbox image, probably on top of a base image with some necessary bits and configuring it to be usable in the CLI environment. It would be very helpful for the development of new shellbox services to have an environment that makes that bit easy.
At the point that the number of services becomes overwhelming, I guess you could consider some layer of configurability on top of the services to bring up a set together for your desired environment
Yep, I was already thinking about this today a little, being able to configure a default set of services that are created with an initial mw docker create, rather than having to do mw docker mediawiki create etc one by one.
The other super important use case that I think is important is for development and testing of new shellbox services. So, it would be good to have a recipe for building a new shellbox image, probably on top of a base image with some necessary bits and configuring it to be usable in the CLI environment. It would be very helpful for the development of new shellbox services to have an environment that makes that bit easy.
Shell box could be a good first example and attempt at making this a development environment for more than just mediawiki.
Right now media wiki is the only app that you can mount development code into, but it would be nice to be able to develop other things in the same way too (if you want to).
Thanks for the thoughts, I may continue looking at this this week.
Initial patch https://gitlab.wikimedia.org/repos/releng/cli/-/merge_requests/138
It's probably best to track anything relating to developing shellbox itself as a separate task if folks want that
This is merged, but I struggled to test this out locally
You should be able to find a binary with shellbox support at https://gitlab.wikimedia.org/repos/releng/cli/-/jobs/7420/artifacts/download
Going to close this, a first version (which could do with some testing) will be in v0.10.0 (releasing later today)