create test scripts to verify pysim-prog ans sysmo-usim-tool with jenkins
At the moment pysim, nor sysmo-usim-tool does have integration tests on jenkins. Especially for pysim-prog.py this is a problem. pysim-prog.py supports various types of simcards now and its becoming hard to check every single one of them during development. We need a script that can automatically verify various card types.
The setup should consist of multiple physical cards and readers. The script then should execute a test write/read operation on each of the cards.
For sysmo-usim-tool the task is similar but with the exception that only one card type is checked and the script can be much simpler
- Status changed from New to In Progress
- % Done changed from 0 to 50
We now have a bash script to verify pysim-prog.py. The script isself is generic. The user has to supply a config file for each card (also scripts but with variables only). The script can then be used to generage a .ok file with pysim-read.py. The cards are automatically probed (see also: https://gerrit.osmocom.org/#/c/pysim/+/9884), so one does not pay too much attention on which card goes into which reader. Also -re enumeration of the readers by pcscd will not hurt.
We now have a bash script to verify pysim-prog.py. The script isself is generic.
The cards are automatically probed (see also: https://gerrit.osmocom.org/#/c/pysim/+/9884), so one does not pay too much attention on which card goes into which reader.
But I presume we do make sure that all expected cards are actually found? We just don't care in whcih slot they are? I'm just asking as the absence of an expected card from the system should cause the test to fail.
Also -re enumeration of the readers by pcscd will not hurt.
- % Done changed from 50 to 80
But I presume we do make sure that all expected cards are actually found? We just don't care in whcih slot they are? I'm just asking as the absence of an expected card from the system should >cause the test to fail.
Thats a good point. I have now added that. If it does not see each expected card once it will exit with 1. Also if a card becomes unresponsive the script will exit with 1.
For sysmo-usim-tool I now have a script that tries out each of the commandline options. I have set -e on here as well, so if sysmo-usim-tool detects an error it will fail. We also might consider to dump the output into an .ok file and diff afterwards. Then we also can verify the actual data contents as well.
All in all I think we have a good coverage now. I will coordninate the jenkins integration with lynxis when I see him next time.
(I also have extended sysmo-usim-tool a bit so that it senses on the ATR of the card. By this we make sure that we always pick the first available sysmo-usim-sjs1 even when various readers with various other cards are connected)
I have discussed the next steps with lynxis today. As a first step I have pushed the pysim-test.sh script I have created into review so it can checked out together with the repository and also be used by other developers if needed. Lynxis will take care of the jenkins stuff (contrib directory).
See also: https://gerrit.osmocom.org/#/c/pysim/+/9947 tests: add test program to verify pysim-prog.py (and pysim-read.py)
I now negotiate with Roh to get a debian host where we can run the build slave on.
(Also I changed the script a bit so that it can be run from any location.)
Roh has set up the test host and connected the readers. Next step is try it on that test-host. I expect that there will be minor fixes required until it works fine with jenkins. We should do the tests with a private branch first and merge the gerrit changes when we are done with everything.
- % Done changed from 90 to 80
I have tried it out today. Pushing a change to gerrit and let it verify by jenkins forts fine. This means we are complete for pysim.
Now we need to see what we can do about sysmo-usim-tool. For this we should discuss tomorrow what we need there. We might have problems there since sysmo-usim-tool is on git.sysmocom.de.
On Mon, Jul 30, 2018 at 10:20:12AM +0000, dexter [REDMINE] wrote:
We might have problems there since sysmo-usim-tool is on git.sysmocom.de.
Not sure why that would cause problems. git.sysmocom.de is a public git server,
just like git.osmocom.org. The build job is simply cloning the publicly readable
repository, it doesn't care from which server.
On Mon, Aug 06, 2018 at 12:19:15PM +0000, dexter [REDMINE] wrote:
The repository for sysmo-usim-tool is not in gerrit. I do not know if this is a problem or not.
gerrit is only required if you want pre-merge tests before accepting a given patch. Those are the
"gerrit" jenkins jobs listed in https://jenkins.osmocom.org/jenkins/view/gerrit/
Probably we can just trigger the testrun from jenkins directly after we have pushed something. Maybe lynxis can say more about that?
this is how all our "master" jenkins jobs in https://jenkins.osmocom.org/jenkins/view/master/ work.
"Build Trigger" is set to "Poll SCM" every 5 minutes. If any commits are detected at the time
of the poll, a new build is started.
There is nothing special required for this, other than a public readable git repo, like it is the
case for sysmo-usim-tool.
- Assignee changed from dexter to lynxis
- % Done changed from 80 to 90
I have now fixed and extended the already existing unit-tests for sysmo-usim-tool. The repository is now updated and all tests are working. It does not matter in which state the test-card is, as long as the ADM1 key in test-data is correct it should work. The tests are executed by running tests/run-tests.
The ADM1 key that is currently in test-data matches the one of the card we have in our test setup so we can now integrate those tests with jenkins.
I have updated the the simtester now so that it also tests gr1. Everything looks good.
But I found it very confusing to find the right location to put the new .data and .ok files, here are the directories I have cycled trough:
simcard testdata is in:
seems to be abandonned:
not tried yet:
I wonder what all those are for and why there are so many of them. Wouldn't be just one enough? If manual triggering requires a commit to gerrit this is no problem. The the only reason why I would want to trigger the test manually is when I make changes to the setup and then I can just do a commit to gerrit. This is also better because then we have more coverage when trying the whole process out.