Check if build is cancellable in client

Bugzilla - https://bugzilla.redhat.com/show_bug.cgi?id=1171673
There is no way to make cancel of a build that is complete or failed from being cancelled.  You cannot guarantee that cancel will propagate to all of the affected systems prior to completion.

An example:

1. Build is in Running
2. User cancels
3. Server updates build Cancelled flag
4. Build completes and tries to update the server

The build actually completed.  The REST object says "cancelled".  The user's *request* to cancel was accepted, which is success.  The user's *intent* was for the build to be cancelled, which did not happen correctly.

You cannot build a system that will always handle cancel correctly.  Instead, you should record the cancel intent, but not mutate a "Completed" or "Failed" build to "Cancelled".  Recording the cancellation is a success operation.  If the build is already cancelled, the user gets what they want.

So for that reason, the client command should not return a non-zero status when the build is in completed or failed state, nor when invoking the command twice.  Cancel is an idempotent action, it records a user intent, and once it has been recorded, the user can continue with their actions.

This means that test-cmd shouldn't fail *EXCEPT* when the user's intent can't be recorded (server not available, build deleted, etc).  This is the problem with cancel as currently implemented that I wanted to convey.

Cancel is like the delete action - it's successful if the intent is recorded, but if the item no longer exists it is also successful.

----- Original Message -----
> > @@ -21,6 +21,26 @@ function cleanup()
> >      echo "Complete"
> >  }
> >  
> > +# Test the cancel-build command. Since the test case is dependent
> 
> > End to end is a test that tests our integration "end to end".
> 
> I know, was I was trying to say is that I'm trying to run a simple command
> and assert it works, `test-cmd.sh` should be the proper place, as you said.
> 
> > if you want to test it there it should be start-build -> cancel build
> > immediately.
> I do just that, the thing is sometimes the build completes very fast and the
> command exists because you can't cancel a complete/failed build. To avoid
> this flaky scenario I'm starting a new build and I print if the method
> worked ok or not, but I let the test run either way. Because the command is
> working properly, just that the environment is sometimes different because
> of the nature of the file.( I don't know if I explained this quite right, I
> hope so.).
> 
> > ThIs highlights why it is wrong to prevent new builds from being canceled.
> 
> I'm not exclude this status in the command, only Complete,Failed,Cancelled.
> Now the code base doesn't take care of the `New` status, I know. I will
> bring it up at the scrum meeting, because we had a talk about this and we
> said we should make this first work for Pending/Running, since New builds
> are handled differently.
> 
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/openshift/origin/pull/542/files#r21534007