Closed williamcroberts closed 3 years ago
Another question, can I move your CI commands into a separate script, it greatly simplifies things.
3 code coverage reports:
That's intentional, because we have #ifdef
s for the different openssl API versions (unfortunately) and we want to report the total coverage over all branches
xenial
That's just what travis had at the time. Should be working on anything else too. I'd love to see the docker-stuff working for this as well
separate script
Sure, love to.
@AndreasFuchsSIT thanks for the response. Okay, Ill flip over to the docker stuff.... let's see what I can get working for ya. Ill leave this ticket open and close it with a PR.
@AndreasFuchsSIT the tests include failwrite.sh. However, this doesn't work in a root environment (root has all capabilities and is allowed to bypass DAC by default), is this test a hard requirement? Is this test not something that can be mocked better?
It was added to test graceful failure, but I guess you knew that...
I guess we could try to open /dev/null/doesnotexist instead ?
It was added to test graceful failure, but I guess you knew that...
I guess we could try to open /dev/null/doesnotexist instead ?
That's not a bad idea. My other thought was to detect the caps and turn down cap dac override. But I like your idea better.
A few questions, in the .travis.yaml file, all gcc builds have coverage enabled: https://github.com/tpm2-software/tpm2-tss-engine/blob/ae070caf92b308ae81d63083784b0ca52222d748/.travis.yml#L104-L108
The matrix build is currently 2x3 yielding 6 builds, 3 of which are gcc. Does this mean you end up with 3 code coverage reports for each build, is that right? Do you want this variability? Things like changing OSSL version could cause code to be included/excluded, etc.
The next questions are: the build is on xenial (thats 16.04 right?), is that a requirement or just arbitrary? Do you know of things breaking offhand switching that out to a newer ubuntu version?