CLI commands returns a '0' instead of '1' for the failures.
Example: ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: pki_user_cli_user_add-CA-040: Add user with --password less than 8 characters :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: Executing: pki -d /opt/rhqa_pki/certs_db -n CA_adminV -c redhat123 user-add --fullName="Test ca_agent" --password=pass ca_agent2 > /tmp/tmp.4PZ2oIqegC/pki-user-add-ca-008.out 2>&1 :: [ FAIL ] :: Add a user --must be at least 8 characters --password (Expected 1, got 0) :: [ PASS ] :: File '/tmp/tmp.4PZ2oIqegC/pki-user-add-ca-008.out' should contain 'PKIException: The password must be at least 8 characters' :: [ LOG ] :: Duration: 3s :: [ LOG ] :: Assertions: 1 good, 1 bad :: [ FAIL ] :: RESULT: pki_user_cli_user_add-CA-040: Add user with --password less than 8 characters <aakkiang> edewata: user-add cli returns a '0' instead of '1' for the failures recently, used to return 1 before <edewata> aakkiang: it's maybe because we change the CLI wrapper recently from perl to python <edewata> aakkiang: and it looks like we're not passing the return code from java properly <edewata> aakkiang: this should affect all CLI commands <aakkiang> edewata: ok, all of the tests where we expected a '1' failed <edewata> aakkiang: ok. yeah, please open a ticket for this. it should be easy to fix.
Per CS/DS Meeting on 3/24/2014 - cleanup component.
Per request from QE at the CS/DS meeting of 4/7/2014, it was determined that this ticket's priority would be raised to 'critical'.
Tested workaround that mharmsen suggested, in /usr/bin/pki change 'subprocess.call(command)' to 'subprocess.check_call(command)', now its returning code '1' for the failures; but help tests where a code '0' is expected is returning a code '1'.
# pki user Commands: user-find Find users user-show Show user user-add Add user user-mod Modify user user-del Remove user user-cert User certificate management commands user-membership User membership management commands Traceback (most recent call last): File "/usr/bin/pki", line 156, in <module> main(sys.argv) File "/usr/bin/pki", line 147, in main run_java_cli(new_args) File "/usr/bin/pki", line 113, in run_java_cli subprocess.check_call(command) File "/usr/lib64/python2.7/subprocess.py", line 542, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['java', '-Djava.library.path=/usr/lib64/jss:/usr/lib64:/lib64:/usr/lib/jss:/usr/lib:/lib', '-cp', '/usr/share/java/commons-cli.jar:/usr/share/java/commons-codec.jar:/usr/share/java/commons-httpclient.jar:/usr/share/java/commons-io.jar:/usr/share/java/commons-lang.jar:/usr/share/java/commons-logging.jar:/usr/share/java/httpcomponents/httpclient.jar:/usr/share/java/httpcomponents/httpcore.jar:/usr/share/java/jackson-annotations.jar:/usr/share/java/jackson-core.jar:/usr/share/java/jackson-databind.jar:/usr/share/java/jackson-module-jaxb-annotations.jar:/usr/share/java/jackson/jackson-core-asl.jar:/usr/share/java/jackson/jackson-jaxrs.jar:/usr/share/java/jackson/jackson-mapper-asl.jar:/usr/share/java/jackson/jackson-mrbean.jar:/usr/share/java/jackson/jackson-smile.jar:/usr/share/java/jackson/jackson-xc.jar:/usr/share/java/jackson-jaxrs-providers/jackson-jaxrs-base.jar:/usr/share/java/jackson-jaxrs-providers/jackson-jaxrs-json-provider.jar:/usr/share/java/jaxb-api.jar:/usr/share/java/servlet.jar:/usr/share/java/resteasy/jaxrs-api.jar:/usr/share/java/resteasy/resteasy-atom-provider.jar:/usr/share/java/resteasy/resteasy-client.jar:/usr/share/java/resteasy/resteasy-jaxb-provider.jar:/usr/share/java/resteasy/resteasy-jaxrs.jar:/usr/share/java/resteasy/resteasy-jaxrs-jandex.jar:/usr/share/java/resteasy/resteasy-jackson-provider.jar:/usr/share/java/pki/pki-nsutil.jar:/usr/share/java/pki/pki-cmsutil.jar:/usr/share/java/pki/pki-certsrv.jar:/usr/share/java/pki/pki-tools.jar:/usr/lib64/java/jss4.jar:/usr/lib/java/jss4.jar', 'com.netscape.cmstools.cli.MainCLI', 'user']' returned non-zero exit status 1
Checked into 'master':
with below versions the return code for failed pki commands are returning 255 instead of 1
[root@dhcp207-176 dogtag]# pki cert-show 0x15343 CertNotFoundException: Certificate ID 0x15343 not found [root@dhcp207-176 dogtag]# echo $? 255
pki-ca-10.2.0-0.1.20140502T0344zgit8084199.fc20.noarch (Build Date: Build Date : Fri 02 May 2014 12:34:05 AM EDT) pki-tools-10.2.0-0.1.20140502T0344zgit8084199.fc20.x86_64 (Build Date : Fri 02 May 2014 12:34:05 AM EDT)
Replying to [comment:7 mrniranjan]:
with below versions the return code for failed pki commands are returning 255 instead of 1 ``` [root@dhcp207-176 dogtag]# pki cert-show 0x15343 CertNotFoundException: Certificate ID 0x15343 not found [root@dhcp207-176 dogtag]# echo $? 255 ``` ``` pki-ca-10.2.0-0.1.20140502T0344zgit8084199.fc20.noarch (Build Date: Build Date : Fri 02 May 2014 12:34:05 AM EDT) pki-tools-10.2.0-0.1.20140502T0344zgit8084199.fc20.x86_64 (Build Date : Fri 02 May 2014 12:34:05 AM EDT) ```
``` [root@dhcp207-176 dogtag]# pki cert-show 0x15343 CertNotFoundException: Certificate ID 0x15343 not found [root@dhcp207-176 dogtag]# echo $? 255
```
``` pki-ca-10.2.0-0.1.20140502T0344zgit8084199.fc20.noarch (Build Date: Build Date : Fri 02 May 2014 12:34:05 AM EDT) pki-tools-10.2.0-0.1.20140502T0344zgit8084199.fc20.x86_64 (Build Date : Fri 02 May 2014 12:34:05 AM EDT)
This is by design -- in the previous iteration of this bug, all error codes from the various java-based CLI tools were set to return "-1" on error and "0" on success.
The python-based "pki" program simply returns the value returned by its java-based CLI tool.
Consequently, if your test scripts are failing, they should only be testing for non-zero based return values (i. e. - [rv != 0]) rather than specific return values such as "-1", "1", "255", etc.
However, if there are cases where any CLI man page is specifically stating an error code return value of "1", this does need to be changed.
Closing as WONT FIX.
Metadata Update from @aakkiang: - Issue assigned to mharmsen - Issue set to the milestone: 10.2 - 04/14 (April)
Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.
This issue has been cloned to GitHub and is available here: https://github.com/dogtagpki/pki/issues/1485
If you want to receive further updates on the issue, please navigate to the GitHub issue and click on Subscribe button.
Subscribe
Thank you for understanding, and we apologize for any inconvenience.
Login to comment on this ticket.