Repository navigation
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1245 +/- ##
==========================================
+ Coverage 94.67% 94.81% +0.13%
==========================================
Files 41 41
Lines 2611 2642 +31
==========================================
+ Hits 2472 2505 +33
+ Misses 139 137 -2 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Do you have a use case that requires this? To my mind this should be tracked in the dodal module, as the device_factory allows setting whether to connect sim or not, rather than having multiple potentially overlapping places to define this. |
tpoliaw
left a comment
There was a problem hiding this comment.
There's currently no way (that I'm aware of?) of marking all device factories as mocks in one change so I can see the motivation for being able to mock an entire beamline in one flag.
This is all about to change though if the device manager change works out so it might be easier to change there? Other than the weirdness it introduces around having mock plans, I'm not against the idea of it being here as well though.
| "kind": "planFunctions", | ||
| "module": "dodal.plans" | ||
| "module": "dodal.plans", | ||
| "mock": false |
There was a problem hiding this comment.
Having a mock field on a plan module is odd. Can we split the Source type into a union where each sub type only has relevant fields?
The use case is the same as the parent issue When hyperion moves to blueapi, we will be launching as standard blueapi plan + device modules, so without this option there will be no way to test it outside of connecting to real devices, if we want to be able to do integration testing. I expect that this will come in handy when I start writing the hyperion-supervisor process, as then I will want to be able to verify that I can launch plans, monitor execution and do things like start and stop |
I agree the configuration is slightly weird, I can investigate changing the Source type. If the device manager will let us do this more neatly that would be ok, but it does need to be something that can be set up via configuration so that I can do things like run I'm not sure what the plan is currently for getting the device manager into dodal - on its own the PR DiamondLightSource/dodal#1549 doesn't provide anything without accompanying changes in dodal device modules and blueapi, and it seems the related discussion DiamondLightSource/dodal#1574 is stalled at the moment. |
type union of Source objects for sources
The change in dodal is mostly complete. For now, both approaches are supported and beamlines can try using the new version when they get a chance. I have made an example change for i04 in #1684. For the blueapi side, the aim is to support the old loading for a short transition period then move everyone to the new system. As part of that I'll make sure mock is support is included. Do you mind if I merge this PR into that change? |
|
Closing this PR in favour of
|
No description provided.