Testing on the Beamline

Normal Testing Process

Artemis should be regularly tested on the beamline (ideally at least weekly), the ideal way to do this is to:

1. Create a PR with the change, tested offline as much as possible
2. Get it reviewed and merged to main
3. Create a release and deploy it

By keeping to this schedule as much as possible we avoid the GDA issue of having many beamlines with code far away from main and having to merge this all at some point. If the code does not work after testing new issues can be created.

Minor testing

There may be some cases where you're not confident that the code you're working on is correct and you would like to test it on the beamline. This should not be a regular occurrence but in this case you should:

1. Switch the production deployment to your code
2. Do the testing, making sure you not all the issues sufficiently so you can test them offline
3. Switch production back to the release tag
4. Get your code merged as soon as possible, ideally within the week

Gotchas

It can sometimes be hard to test on beam off days as GDA has code ensuring there is beam before running Artemis. You can fool GDA into thinking there is beam by running beam_off_trickery.sh. This script will run continually (i.e. look like it's hung) but whilst it's running GDA will run w/o beam. On killing the script GDA will revert to checking for beam. Logging out of the machine running it will kill the script. You should run it on a beamline workstation, not on the control machine.