Ravenbrook / Projects / Perforce Defect Tracking Integration / Issues
Perforce Defect Tracking Integration
| Title: | It is not possible from the result of "p4 -G job -o jobname" to tell whether a job has been returned, or an error message |
| Status: | closed |
| Priority: | optional |
| Assigned user: | gdr |
| Product: | p4dti |
| Organization: | Ravenbrook |
| Description: | It is not possible from the result of "p4 -G job -o jobname" to tell whether a job has been returned, or an error message. The result of "p4 -G job jobname" is a marshalled Perforce dictionary. In the event of an error, the result looks like { 'severity': 3, 'data': 'error message', 'code': 'error', 'generic': 1 }. If a job is returned, the result is a dictionary mapping job field names to job field values, plus 'code': 'stat'. However, if the administrator changes the jobspec so that it has fields called 'severity', 'data', 'code' and 'generic', it is possible for a genuine job to have exactly the same appearance as an error. In this case it would be impossible to determine whether an error had occurred. The problem is due to mixing control signals with data. |
| Analysis: | It is critical that we fix this, otherwise we risk inconsistent results if a job is mistaken for an error or vice versa, and hence failing to meet requirement 1. GDR 2000-09-13? Chris Seiwald suggests using the 'code' field to determine whether the result is an error or a job, and documenting the fact that defining a 'code' field in the jobspec is a bad idea [Seiwald 2000-09-11]. Since we're generating the jobspec in most cases we can simply avoid making a field called "code" and avoid this problem. We can also document this subtlety for people who want to configure the system with their own jobspecs. RB 2000-11-28 This corresponds to Perforce job job004093. A workaround would be to use "p4 -G jobs -e job=JOB" instead of "p4 -G job -o JOB". GDR 2001-03-09 |
| How found: | manual_test |
| Evidence: | [GDR 2000-09-11] "When using p4 -G, how do I distinguish errors from data?" (e-mail message); Gareth Rees; 2000-09-11; <URL: http://info.ravenbrook.com/mail/2000/09/11/10-53-01/0.txt>. [Seiwald 2000-09-11] "Re: When using p4 -G, how do I distinguish errors from data?" (e-mail message); Chris Seiwald; 2000-09-11; <URL: http://info.ravenbrook.com/mail/2000/09/12/05-51-03/0.txt>. |
| Observed in: | 2000.1 |
| Introduced in: | 0.0.0 |
| Test procedure: | <http://www.ravenbrook.com/project/p4dti/master/test/test_p4dti.py>, section 6.3 |
| Created by: | gdr |
| Created on: | 2000-09-13 18:08:21 |
| Last modified by: | gdr |
| Last modified on: | 2001-12-10 18:53:53 |
| History: | 2000-09-13 GDR Created. 2000-11-28 RB Split description and analysis. Added solution to analysis. Set priority to "optional". Assigned to Ravenbrook for workaround. 2000-11-30 GDR Closed. The automatic configuration engine never creates a field called 'code', and section D.2 of the administrator's guide tells people not to create such a field. |
| Change | Effect | Date | User | Description |
|---|---|---|---|---|
| 5172 | closed | 2000-11-30 14:00:18 | gdr | Added note to section D.2 pointing out that you can't have a field in the jobspec called "code". |
| 5048 | open | 2000-11-28 12:25:34 | gdr | The configuration generator prevents people from having a field called "code" in their Perforce jobspec. This is because "p4 -G" uses the "code" field to indicate success or failure of the command. See job000003 for more details. |
Generated at 2008-07-09 03:05:24 by $Id: //info.ravenbrook.com/infosys/cgi/issue.cgi#430 $
Copyright © Ravenbrook Limited. This document is provided "as is", without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this document. You may make and distribute verbatim copies of this document provided that you do not charge a fee for this document or for its distribution.