Bug 1668

Summary:	bake build 'stop on error' option
Product:	bake	Reporter:	Tom Henderson <tomh>
Component:	bake	Assignee:	Daniel Camara <daniel.camara>
Status:	RESOLVED FIXED
Severity:	enhancement	CC:	ns-bugs
Priority:	P5
Version:	unspecified
Hardware:	All
OS:	All

Description Tom Henderson 2013-05-03 01:30:15 UTC

one nice enhancement would be to provide some kind of stop on error command line option, to make bake stop the build upon the first error, even if the build component is optional.

I have noticed in testing bake that I'm repeatedly scrolling up or running bake through script so that I can go back later and find (and fix) the build issue that was found earlier.

Comment 1 Daniel Camara 2013-09-06 02:46:45 UTC

Fixed at changeset 275.

 A new option --stop_on_error was created and it will stop if an error occurs in any of the main bake functions, (download, build, deploy, clean, update). At the first error found a message is given to the user and the process stops so that the user can fix the error before continuing.

Comment 2 Tom Henderson 2013-09-06 09:14:11 UTC

Could you do some more work on this?

- this new option doesn't seem to be documented anywhere
- it seems to result in an exit code of 0, suggest 1 instead
- it introduces underscores in the option where previous show-builtin uses hyphens, suggest to make it "stop-on-error" for consistency

Comment 3 Daniel Camara 2013-09-11 04:48:05 UTC

Fixed at changeset 277.

No serious effort was done on the standardization of the tags, the stop_on_error was changed to stop-on-error and these other tags were changed to "harmonize" the parameters. 

--force_clean -> --force-clean
--target_file -> --target-file
--stop_on_error -> --stop-on-error
--environment_file_identification -> --environment-file-identification
--no_environment_file -> --no_environment_file

----
 Apart from the standard --help message, that is standard on the code, a new section on the documentation was added to call the attention to the user to the stop-on-error parameter.

--- 

  The result should be always 1, can you give me an example when it is not?

Comment 4 Tom Henderson 2013-09-11 09:59:41 UTC

(In reply to comment #3)
> Fixed at changeset 277.
> 
> No serious effort was done on the standardization of the tags, the
> stop_on_error was changed to stop-on-error and these other tags were changed to
> "harmonize" the parameters. 
> 
> --force_clean -> --force-clean
> --target_file -> --target-file
> --stop_on_error -> --stop-on-error
> --environment_file_identification -> --environment-file-identification
> --no_environment_file -> --no_environment_file
> 
> ----
>  Apart from the standard --help message, that is standard on the code, a new
> section on the documentation was added to call the attention to the user to the
> stop-on-error parameter.
> 
> --- 
> 
>   The result should be always 1, can you give me an example when it is not?


I was looking at pre-commit code when I wrote that; I think it is OK.  However, I suggest a non-zero code for a control-C abort (bash uses 130):

     1.4  def signal_handler(signal, frame):
     1.5      """ Handles Ctrl+C keyboard interruptions """
     1.6      
     1.7 -    print (' > Bake was aborted! (Ctrl+C)')
     1.8 +    print (os.linesep + ' > Bake was aborted! (Ctrl+C)')
     1.9      os._exit(0)

http://tldp.org/LDP/abs/html/exitcodes.html

Comment 5 Daniel Camara 2013-09-11 17:47:13 UTC

> I suggest a non-zero code for a control-C abort (bash uses 130):
> 
>      1.4  def signal_handler(signal, frame):
>      1.5      """ Handles Ctrl+C keyboard interruptions """
>      1.6      
>      1.7 -    print (' > Bake was aborted! (Ctrl+C)')
>      1.8 +    print (os.linesep + ' > Bake was aborted! (Ctrl+C)')
>      1.9      os._exit(0)

 Fair, I changed to 130 in the changeset 278