Page MenuHomePhabricator

Build a dev/testing environment for webservice that would make it easier to get people involved in fixes
Open, MediumPublic


A testing environment for something like webservice might take an interesting bit of magic to make work quickly, but it would help any contributor (including toolforge admins) work on it more efficiently.

Ideas are things like a docker-compose or some kind of vagrant setup, perhaps.

Event Timeline

Bstorm triaged this task as Medium priority.Apr 3 2019, 11:06 PM
Bstorm created this task.

I recently did this in a tool to make testing some major changes to webservice shell easier:

$ cd $HOME
$ python3 -m venv venv.bastion
$ source venv.bastion/bin/activate
$ echo 'source $HOME/venv.bastion/bin/activate' >> $HOME/.profile
$ pip3 install -U pip wheel
$ git clone
$ pip3 install -e $HOME/tools-webservice

After applying all of this, which webservice finds the version in $HOME/venv.bastion/bin first. That file is a stub that loads and executes the contents of $HOME/tools-webservice/scripts/webservice. Edits to files in $HOME/tools-webservice are live immediately. I think this is basically the same thing that @Bstorm has been doing for a while to test webservice changes in toolsbeta.

The only part of working on webservice this does not support testing is changes to the webservice-runner script which is embedded in the Docker images. I think we are stuck with that unless we make some deeper changes in how the pods launched by webservice work. We might be able to do something interesting using init containers if we wanted to fix this last bit. The general idea I have for that is that we could stop putting webservice-runner (and the rest of the webservice code base) into our container images directly. Instead we could use an init container to populate a Volume that is mounted into the main container and used from there. This could have other benefits for easing deploys of webservice too, but would take a bunch of testing. But if we had that, we could also have some "developer mode" feature that would let you swap out the normal init container for one that instead injected your locally modified versions into the pod.