-
Notifications
You must be signed in to change notification settings - Fork 181
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable container logging and add large test logic and documentation #386
Conversation
Closes #352 |
This is great! As discussed at today's meeting, I suggest we add steps for capturing this data on an ongoing basis (both performance and success/failure rates) so we can compare release-to-release. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I made a first pass of the code for this feature. Aside for some changes in the way we handle process output, due to its sensitive nature, I don't have much else to comment on. I'm eager to see this merged!
Reminder, this PR will effectively close #319, so let's update the commit messages as well. |
I have rebased the PR from main. So it now includes all the Qubes-integration stuff. @apyrgio I also considered following your suggestion of sending data via stdout as soon as it's generated. However, I remembered why I had chosen not to do it: it would affect docker as well. When you send data via stdout on docker, we should revert this and make use of both stdout and stderr. |
Question, how does this PR affect our QA? Should we add a section where we ask devs to run the tests in a specific environment and capture the results? |
We are thiiis close to having it ready for 0.4.2, but unfortunately we won't make it. We have to push this again to 0.5.0. |
Besides the above comments, I have two more general ones:
Other than that, I think we are very close to merging it. |
a0dbf9b
to
378ec1c
Compare
OK. Leaving this as-is now. It would require passing the
Sorry about that. I've done already a lot of that in earlier commits because the whole PR changed based on feedback and main changing already for too releases. So this is a 'best effort' but probably won't be perfect in the end. So after approval, I'll do some final squashing. |
I've resolved all the conversations. Feel free to merge! |
c56c7dd
to
fb560b1
Compare
Use qrexec stdout to send conversion data (pixels) and stderr to send conversion progress at the end of the conversion. This happens regardless of whether or not the conversion is in developer mode or not. It's the client that decides if it reads the debug data from stderr or not. In this case, it only reads it if developer mode is enabled.
Ensure a server cannon keep the client hannging if more data than necessary is sent. This applies to container and the Qubes implmentation.
Store the conversion log to a file (captured-output.txt) in the container and when in development mode, have its output displayed on the terminal output.
Certain characters may be abused. Particularly ANSI escape codes. Solution inspired by Qubes OS's hardening of ther RPC mechanism [1]: > Terminal control characters are a security issue, which in worst case > amount to arbitrary command execution. In the simplest case this > requires two often found codes: terminal title setting (which puts > arbitrary string in the window title) and title repo reporting (which > puts that string on the shell's standard input. [sic] > > -- qvm-run.rst [2] [1]: QubesOS/qubes-core-admin-linux@e005836 [2]: https://github.com/QubesOS/qubes-core-admin-client/blob/c70da44702109b45d960c7de170ab8c2820b7167/doc/manpages/qvm-run.rst?plain=1#L126
Add GPG-styled "armor" around conversion logs -----CONVERSION LOG START----- Creator: Writer Producer: LibreOffice 6.4 [...] -----CONVERSION LOG END-----
Adds a large pool of document that can and should be used prior to a release to understand effects of the new release over a real-world scenario. Documents are stored in an external git LFS repo under `tests/test_docs_large` and currently it's about 11K documents gathered from multiple PDF readers and office suite's test sets. Documentation on how to run the tests is under `docs/developer/TESTING.md`
Log commands so we can trace back which errors / outputs are from each command.
In the junitxml this prefix would look ugly (">>>") because it has to escape any non-xml tags.
Reporting script now parses JunitXML instead of a series of ".container_log" files. The script in in changed submodule. Additionally it makes failed tests actually fail so that this is recorded in the JunitXML report.
Some tests are expected to fail. To avoid having potentially thousands of tracebacks of the failed docs at the end, we're deactivating that reporting.
fb560b1
to
89365b5
Compare
Adds a large pool of document that can and should be used prior to a release to understand effects of the new release over a real-world scenario.
Documents are stored in an external git LFS repo under
tests/test_docs_large
and currently it's about 11K documents gathered from multiple PDF readers and office suite's test sets.Documentation on how to run the tests is under
docs/developer/TESTING.md
Fixes #319