The latest mxcubeweb is never tested against the latest mxcubecore

[fabcor-maxiv]

The way our GitHub Actions workflows (CI pipelines) are setup the latest mxcubeweb is tested against the currently pinned version of mxcubecore.

This leads to incompatibility issues between mxcubecore and mxcubeweb to remain undetected for some time...

---

See this line, where it shows that we install with Poetry which means the poetry.lock file is taken into account and it is the pinned version of mxcubecore that is installed for the tests:

mxcubeweb/.github/workflows/build_and_test.yml

Line 53 in e0b3ab7

run: "${MAMBA_EXE} run --name mxcubeweb poetry install"

Here in mxcubeweb, the currently pinned version of mxcubecore is 1.133.0:

mxcubeweb/poetry.lock

Lines 1750 to 1759 in e0b3ab7

	[[package]]
	name = "mxcubecore"
	version = "1.133.0"
	description = "Core libraries for the MXCuBE application"
	optional = false
	python-versions = "<3.12,>=3.8"
	files = [
	{file = "mxcubecore-1.133.0-py3-none-any.whl", hash = "sha256:8551fe449d7eb85ab419831dade7ba4f118a63bbe032620a88302e4a5fb47538"},
	{file = "mxcubecore-1.133.0.tar.gz", hash = "sha256:70fd41417ec8e13ca00720d7fb82247f12bda60b789bc7ef16a5acfb4360bec3"},
	]

---

The current latest tagged version of mxcubecore is 1.142.0:

https://github.com/mxcube/mxcubecore/blob/61b7828cac708f17b4039ebd3a0632c477a1ace4/pyproject.toml#L3

---

So currently the mxcubeweb CI pipelines test against a quite outdated version of mxcubecore.

Maybe we should look into this, investigate how bad the damage could be, think of processes and technical solutions to minimize undetected issues.

[fabcor-maxiv]

Examples of issues that might have been detected:

• Pytests fail when using latest mxcubecore (v1.142.0) #1370
• UI hangs on loading screen after login when using latest mxcubecore (v1.142.0) #1372

[marcus-oscarsson]

How about using ^ in the dependency list ?

[fabcor-maxiv]

How about using ^ in the dependency list ?

Would not change anything because it is still the version pinned in poetry.lock that would be installed.

[axelboc]

Saw this recently: https://docs.astral.sh/uv/concepts/workspaces/ — not a drop-in solution, obviously...

[marcus-oscarsson]

How about using ^ in the dependency list ?

Would not change anything because it is still the version pinned in poetry.lock that would be installed.

Indeed, it would mean that we have to re-generate poetry.lock. Would it make sense to test against the pinned version and create sort of a "smoke" test for the latest version in a separate pipeline ?

[fabcor-maxiv]

There is a lot of aspects to consider in this topic. I do not believe there is one quick and easy solution. I also do not believe that we need to aim for perfect airtight solution. I believe maybe we can minimize such issues by doing some careful changes in tooling and process.

Anyway, one aspect of this, is that in principle, for each tagged version in CORE we should check that it does not break WEB. If it breaks WEB, then this version of CORE should be excluded from the valid dependencies range.

Would it make sense to test against the pinned version and create sort of a "smoke" test for the latest version in a separate pipeline ?

Yes, something along those lines would probably help. This is probably a very good ratio effort vs. value.

Maybe important is to decide what we want to achieve, what rules are we setting for ourselves. Do we want to set as a policy that latest tagged WEB should work with latest tagged CORE? Or something else?

Saw this recently: https://docs.astral.sh/uv/concepts/workspaces/ — not a drop-in solution, obviously...

Yes, maybe that could help. But I would be careful about those new Python dev workflow tools (uv, rye, hatch, pdm, and so on), they are all somewhat new and have lots of breaking changes. I feel like Poetry is just now finally stable enough for a long enough time : D

[rhfogh]

One approach would be to always test against current web and current core versions. If you are making changes in tandem you might want to specify a specific version combination but otherwise, if current web does not match current core then surely there is something wrong?

[axelboc]

I'm pretty sure it's possible to trigger workflows across repositories. Let's dream big:

1. Open PR for my-branch in mxcubecore
2. Trigger a workflow W1 in mxcubeweb.
3. W1 checks out my-branch of mxcubecore and installs it from source.
4. W1 runs all mxcubeweb tests and reports back with a comment in the PR on mxcubecore.
5. Fix my-branch if it broke mxcubeweb unexpectedly, or simply ignore the breakage if it's expected.
6. Merge my-branch into main and wait for tag to be created.
7. Trigger workflow W2 in mxcubeweb, now testing against the latest tag of mxcubecore.
8. If W2 fails, open a PR in mxcubeweb to upgrade mxcubecore to the latest tag.

[marcus-oscarsson]

@rhfogh: Yes indeed current web should always work with latest core.

[marcus-oscarsson]

@axelboc: yes thats a nice idea :) seems like a reasonable and doable test