Make the test correspond to the new beam size handling.

[beteva]

1. Change the type to be str and not int
2. Define aperture and not slits to be the default beam size definer.

Needs the mxcubecore fixes. Partly solves #1370.

[elmjag]

I tested this branch with latest mxcubecore (v1.145.0), I needed to make this change:

diff --git a/test/test_beamline_routes.py b/test/test_beamline_routes.py
index ccbb2c52..c1143e77 100644
--- a/test/test_beamline_routes.py
+++ b/test/test_beamline_routes.py
@@ -21,6 +21,7 @@ def test_beamline_get_all_attribute(client):
 
     expected = [
         "beam",
+        "beam.aperture",
         "cryo",
         "data_publisher",
         "detector",

With the patch above, all tests pass. \o/

Also, I guess we need to change the earliest required mxcubecore version to v1.145.0 here: https://github.com/mxcube/mxcubeweb/blob/develop/pyproject.toml#L44

[elmjag]

nice, now the tests are passing for me!

[fabcor-maxiv]

I'm sorry to have to bring this up, but I believe we should avoid this kind of things:

* 4e885e64 Also update requirements
* 7f2f962f Upgrade lock file
* fe55ba3d Upgrade mxcubecore version.

This should have been one single commit.

I did spend some time working on the pre-commit hooks to prevent exactly this. Are they not working as expected? I can probably fix them if it is the case and you let me know. : )

[beteva]

I did spend some time working on the pre-commit hooks to prevent exactly this. Are they not working as expected? I can probably fix them if it is the case and you let me know. : )

You are absolutely right. I've just forgotten to run the pre-comit. It works really well indeed.

[fabcor-maxiv]

The issue is that we now have some commits in the repository that we know 100% for sure that they have defects, and we perfectly knew that they had defects before merging them. The CI checks told us so.

Forgetting the pre-commit hooks, is no problem at all, but...
If the GitHub CI checks fail, it should NEVER be solved by adding more commits, it should be solved by fixing the commit itself (i.e. amend the commit).

Squashing the commits when merging the pull request could help getting rid of the defective commits as well of course, even though that would not be my preference. My preference is 1 single commit per pull request, which then obviously avoids this kind of issues.

I picked this particular example I highlighted above because it is relatively harmless, but still...
Which commit should I revert if for whatever reason I want to roll-back to the previous mxcubecore version?