ome / omero-figure

An OMERO.web app for creating Figures from images in OMERO
http://figure.openmicroscopy.org
GNU Affero General Public License v3.0
15 stars 30 forks source link

On release, update omero-server Docker with export script #547

Open will-moore opened 3 months ago

will-moore commented 3 months ago

See https://forum.image.sc/t/omere-figure-export-pdf-does-not-work/39573/30

On release, we should update the omero-server Docker with the Pdf export script, as well as the omero-web Docker. That way, it will always be installed for users, without needing complex workflows as described above.

imagesc-bot commented 3 months ago

This issue has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/omere-figure-export-pdf-does-not-work/39573/31

RichardJActon commented 3 months ago

This branch of my fork of omero-server-docker adds omero-figure to the python plugins installed in the ansible playbook so it is available in the server image by default and adds a script which auto-updates Figure_To_Pdf.py to the version in the latest tagged release of omero-figure.

It does this by querying the github API to get the hash of the commit of the release and pulling Figure_To_Pdf.py from that commit.

https://github.com/RichardJActon/omero-server-docker/tree/omero-figure-auto-update

Happy to open a PR with this if you approve of the general approach.

jburel commented 3 months ago

@will-moore this applies to any of the apps included in https://github.com/ome/omero-web-docker/blob/master/standalone/Dockerfile I raised the issue a while back since we only release the docker image on a new release of omero-web We will need to introduce a new tag e.g. 5.25.0-x each time a new app is release.

will-moore commented 3 months ago

@jburel Are there any issues with using 'exotic' tags like that? One alternative option is to not tie the tag to server version and use e.g. Date-based tags which might make it possible to automate the tag (e.g. https://github.com/dncrews/date-tag although this is a JS-based tool). But that maybe more of a breaking change. Thanks @RichardJActon - I don't know much about Docker, but I would think that if we can automate this as much as possible then that would be a big win.

jburel commented 3 months ago

@will-moore no we already used it. It is something to discuss with the wider group.

As for the automation, we already have things in place via GHA e.g. https://github.com/ome/omero-web-docker/pull/64 We could easily apply the logic for apps.

RichardJActon commented 3 months ago

It occurred to me that there might be a better way of automating getting the scripts from the various packages into the right places in the docker image and ensuring that they are consistent with the installed package versions that does not rely on making potentially brittle API calls to github during the build process.

It depends if python packages have an analog of this feature or not - I'm not sure I've not done a lot of python packaging. In R packages there is a folder inst that you can include in your package which is the sanctioned way of having files, such as additional scripts, in your package copied directly into the installation directory of the package. If there is an equivalent for python packages then copying or linking the scripts from where they get installed in the venv to the location that OMERO.server expects to find them would be a more reliable approach than the one I initially took - anyone know if the python packaging format officially supports something like this?

jburel commented 3 months ago

It is not just the script , it is also its dependencies that potentially need to be updated. Figure is the only app at the moment that requires a server-side change.

RichardJActon commented 3 months ago

Indeed - so to clarify, the desired sequence of events is:

  1. A new version of omero-figure gets a tagged release
  2. A github action monitors for this and attempts to rebuild the OMERO.server image, pushing it to dockerhub if this is successful*.

To be successful the image rebuild with the latest omero-figure needs to:

  1. Update the omero-figure package in the venv, along with any dependencies
  2. Copy the omero-figure script to the location expected by OMERO.server

Setting aside triggering the rebuild with github actions for a moment and thinking about what needs to change in Docker build to update omero-figure, we need as I understand it, to:

  1. Add omero-figure to the additional python packages in the ansible playbook - if a new release has been made running this should presumably fetch that and it dependencies
  2. get the latest version of the omero-figure scripts (which is just Figure_To_Pdf.py at the moment) to the right directory in the docker image.

There are two approaches I can think of to updating the script(s):

  1. fetch them from the github release - as already implemented in my script
  2. (after some googling about how to do this in python) add them as package_data in the setuptools config https://setuptools.pypa.io/en/latest/userguide/datafiles.html# and copy them to the right place during the docker build.

I would suggest that the latter option is the preferable approach as it creates a tight coupling between the package installed and the version of the script being used. It also does not make additional calls to external sources during the image build which are brittle and could fail breaking the image build.

EDIT:

*The web client image should probably also have a rebuild triggered on an omero-figure release so the client is in sync with the server.