The new Makefile-based command ``make serve-selenium-notebooks`` will serve notebooks in lib/galaxy_test/selenium/jupyter.
The notebooks will target a Galaxy host running on port 8080 - but are parameterized to be run with papermill (https://papermill.readthedocs.io/) for automate targeting different Galaxy servers, remote Selenium servers, etc..
Screenshots will be embedded right into the notebook.
Example notebooks setup to target just the library code in ``galaxy-selenium`` as well as one appropriate to leverage the Galaxy testing framework are included and documented in depth via modules docstring for ``galaxy_test.selenium.jupyter``.
An extended version of the library functions in #10783 - to allow interacting with workflows, etc.. creating using the API from Selenium. Should make my test prototyping environment in #10784 a bit closer to test case enviornments and allow more rapid development of test cases.
- Rename get_master_api_key to get_admin_api_key - less offesnive and more accurate since it doesn't need to be the bootstrap key.
- Add types and cleanup docstrings.
- Consistent abstract methods with consistent implementation signatures.
- Add a bunch of types to methods to ensure mypy gets in there and checks everything it can while also improving the docs.
- Fix a bunch of issues where Base*Populators were using ``galaxy_interactor`` instances directly - which is bad since the whole point is to not require one of those to execute those methods.
sphinx isn't rendering the types on the abstract properties - which makes me sad but I'm confident that will be fixed at some point. I did change some dependents around to ensure the type annotations are being used by mypy in this case and and they are.
This fixes https://github.com/galaxyproject/galaxy/issues/11125, which
became a problem with https://github.com/galaxyproject/galaxy/pull/10814
and the recent removal of the docker runtime from kubernetes.
This is the quick fix, but I don't like the guessing and disabling
that we do if docker is not available or not functional.
I'm hesitating between adding a config option for the resolver
(`docker_cli_available` or `docker_list_images` + `docker_pull_images`)
and adding a `KubernetesContainerResolver` / `RemoteContainerResolver`
class that doesn't assume docker is available for listing and pulling
iages.
Not wanting to list/pull images on the Galaxy node is probably a
reasonable thing outside of kubernetes as well, so I tend to
go with a `RemoteContainerResolver` class in dev ?
John Chilton