Page MenuHomePhabricator

[mwcli dev] Investigate and possibly implement shellbox workflow
Closed, ResolvedPublic

Details

TitleReferenceAuthorSource BranchDest Branch
[docker] add shellbox supportrepos/releng/cli!138addshoreshellboxmain
Customize query in GitLab

Event Timeline

Addshore created this task.
Addshore moved this task from Inbox to Backlog on the mwcli board.

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? :/

Addshore moved this task from Backlog to In Progress on the mwcli board.

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.
...
We could also define an image to build that would have ALL of the needed libraries for development.

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)