-
Notifications
You must be signed in to change notification settings - Fork 201
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
Test suite: If holding supported, add a new print job for cancelling #438
base: master
Are you sure you want to change the base?
Conversation
@shirelyhhdl @sp1ritCS please test it and let me know whether it helps. |
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.
The only problem with this change is that the "ipp-1.1.test" file is also meant to test real printers, many of which will not support job-hold-until. So the use of job-hold-until should be made conditional on whether job-hold-until is supported.
062f126
to
ca93a96
Compare
@michaelrsweet I haven't found out how to make a specific attribute optional, so I've added a new print job with job-hold-until if the printer supports it, and adjusted requests count in run-stp-tests.sh accordingly. |
I don't know how soon I'm able to test it, but I'll try |
@sp1ritCS @shirelyhhdl any updates? @michaelrsweet WDYT about the changes? |
On some quicker machines the print-job operation finishes quicker than we can cancel it in the test - so add job-hold-until job template attribute if the printer supports it, which will hold the job until it is cancelled by the next test. The next test passes because it has both statuses (correct and error one) as expected, but cupsd generates an additional error in log if the job cancelling fails, which would be more dirty to cover in run-stp-test.sh. There is a loophole when the error is still generated - if the printer/machine is quick enough to finish the job, but the machine/printer doesn't support job holding at the same time. IMHO the current patch should cover most cases.
ca93a96
to
851dc81
Compare
On some quicker machines the print-job operation finishes quicker than
we can cancel it in the test - so add job-hold-until job template
attribute if the printer supports it, which will hold the job until it
is cancelled by the next test.
The next test passes because it has both statuses (correct and error one)
as expected, but cupsd generates an additional error in log if the job
cancelling fails, which would be more dirty to cover in run-stp-test.sh.
There is a loophole when the error is still generated - if the printer/machine
is quick enough to finish the job, but the machine/printer doesn't support job
holding at the same time. IMHO the current patch should cover most cases.
Fixes? #155