search

labgrid-project / labgrid

Embedded systems control library for development, testing and installation
https://labgrid.readthedocs.io/
Other
327 stars 164 forks source link

pytest doesn't exit if someone else kicked and acquired same place #450

Open spark5 opened 5 years ago

spark5 commented 5 years ago

Issue: pytest checks only at init time if the target is acquired. Whenever someone else kicks current user and acquires the place, pytest should exit.

Emantor commented 5 years ago

Pytest checks the locked status only on startup because this requires the setup and run of an async-loop. I'd consider this more of a user issue, you should be absolutely sure that the current user is not using the place at the moment and you can kick him.

spark5 commented 5 years ago

Well, I assume that locking the place means "I am using the board". Issue arrives when a CI app needs to lock a board which is being used by a normal user. The CI has more priority than user and it will kick the user. However, the user won't notice anything, because pytest won't stop execution.

Emantor commented 5 years ago

IMO CI should not be allowed to kick developers and this is more of a peoples problem which can't be solved by software. For the CI use case there is also the Remote Target Reservation Idea which should allow a more seamless sharing of boards between developers and CI.

spark5 commented 5 years ago

What do you mean with Remote Target Reservation Idea ?

Emantor commented 5 years ago

I fixed the link, I pasted the wrong one before.

spark5 commented 5 years ago

I read the Remote Target Reservation Idea and it seems to be a major feature in labgrid. However, the CI systems can use labgrid using wrappers when locking a board. Say, a board needs to be locked, you can sleep a few seconds and try again until a timeout is reached or not.

If a CI system is designed to have more priority than regular users, then it doesn't matter if the regular user was running some heavy tests on the board, because the CI system will kick the current user. But the regular user won't notice anything, because pytest won't exit. Also, the CI system will be influenced by what the previous pytest was doing.

Are you planning to tackle this situation?