Design questions

[joshmoore]

• Should this repo be merged into https://github.com/openmicroscopy/omero-test-daemon-c7-docker?
• Should this be renamed omero-test-infra?
• Should .omeroci/test-data be run in a client docker or the server docker?
• Should we use travis-folds everywhere?

TODO:

• Make Dockerfile in lib-docker (et al) configuration for multiple build systems (mvn, gradle)
• Rename test-data to setup

[sbesson]

Re omero-test-daemon-c7-docker, it would make sense to re-use it from a historical perspective, considering the former as version 0.0.1. of what this is trying to achieve. I don't know if we'll end up doing git rm && git add though Should https://hub.docker.com/r/openmicroscopy/omero-test-daemon-c7/ be deprecated/dropped? If we are not reusing the repository, we should probably deprecate, archive and redirect it to the new testing infrastructure.

I would vote for keeping the omero-* convention when possible. omero-test-infra would work for me.

What are the pros and cons of running omeroci/test-data either on the client docker or server docker? Are there cases where we would like to configure in which location this should be run? In which case, we could probably make that configurable using the filename or more advanced strategies.

[jburel]

I will make sense to re-use if https://github.com/openmicroscopy/omero-test-daemon-c7-docker if possible

for the name I agree with @sbesson we should keep omero- as a prefix.omero-test-infra is a good as any and I don't have a better suggestion

[joshmoore]

I've renamed this repo to omero-test-infra and the following 4 PRs are green:

• [*] pip installable omero-cli-render#1
• [*] Run tests in travis rOMERO-gateway#22
• [*] Test in travis omero-scripts#136
• test omero53 in travis omero-mapr#23

I was hoping to extract the PyTest command and make use of ome/openmicroscopy#5585 but it's too difficult to consume the devspace OMERO.server build. (Here we need a decoupled python-omero or python-omero-testlib)

My proposal would be to merge all 4 of those, perform a release where appropriate, and then consider this version 0.1.0 of the new test infra. I'd don't see a straight-forward way to reuse omero-test-daemon but if it's worth it, I'll invest more time.

[joshmoore]

Few decisions that have been made over scattered conversations (open for veto):

• [*] rename test-omero to omero-test-infra
• rename .omeroci to .ome
• rename .omero to .ome/omero-server
• add an .ome/meta.yml file including the likes of:
  • tag prefix
  • type of application, e.g. "I'm a web plugin"
  • ...

[joshmoore]

Discussion with @jburel and @sbesson today:

• We'll soon need app-build and perhaps add-test (if not also, app-robot, etc).
• Before we start adding such phases, propose to tag this as 0.1.0 including any final naming changes that are desired so we can begin iterating.

[jburel]

app-build already exists. it is currently used to run the tests
This might need to be renamed

[jburel]

I had to make various modifications to use test-infra for figure and iviewer
(more adjustments due to iviewer repo layout)
I will hopefully have a PR tomorrow so we can start a discussion

[jburel]

Changes to have iviewer and figure work with test-infra
#3

[jburel]

Current implementation assumes that the scripts to test are in a folder omero
we will need to relax to handle case like gs/metadata.py
I had to make an change to work with figure but we should consider to go a step further

[jburel]

Changes have been made in #3 to handle scripts not directly under /omero
Looking at other repositories e.g. https://github.com/openmicroscopy/omero-example-scripts
Ignoring the fact that it is not pip installable, there is a "flat" structure. This won't handle by the current implementation or changes in #3

[jburel]

Consider more configuration options for apps e.g. open_with