Skip to content
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

Runner returns success when check failed #54

Closed
sebastiaanluca opened this issue Feb 8, 2016 · 4 comments
Closed

Runner returns success when check failed #54

sebastiaanluca opened this issue Feb 8, 2016 · 4 comments
Assignees
Labels
bug

Comments

@sebastiaanluca
Copy link

@sebastiaanluca sebastiaanluca commented Feb 8, 2016

The point here is that using $result = $this->runner->run($configuration); the following should return false when a check failed: $result->wasSuccessful(). But in my test case, it returns true as in success. While it should return that the entire backup failed because the check failed, right?

Debugged it and boils down to this (I could be totally wrong though):

  1. Added a check to a backup
  2. Check fails and https://github.com/sebastianfeldmann/phpbu/blob/master/src/Result.php#L285 is called. This adds a failed check and also fails the backup.
  3. This only updates the backup, not the result which is used to determine a successful backup run! This is done here: https://github.com/sebastianfeldmann/phpbu/blob/master/src/Result.php#L133 where the value being used (backupsFailed) is only updated when a backup itself failed (https://github.com/sebastianfeldmann/phpbu/blob/master/src/Result.php#L237). The checksFailed value is not being used anywhere except in the verbose CLI logging, I think?

In short, shouldn't wasSuccessful in the result class also check for failed checks, syncs, … instead of just backups?

@sebastianfeldmann
Copy link
Owner

@sebastianfeldmann sebastianfeldmann commented Feb 8, 2016

Hi,
$result->wasSuccessful() currently focuses on pure backup execution. I admit this is somehow confusing.
The method you could use right now is $result->allOk()
Sadly the current version has a bug and is missing to validate some values.
From todays point of view this whole skip, fail, success mixing makes my head hurt and I should simplify this in the future.

This
46b8eb2
fixes the $result->allOk() bug

But I think you are right, a failing check should fail the backup as well.
There's actually a test called

public function testBackupFailedOnFailedCheck()
sebastianfeldmann added a commit that referenced this issue Feb 8, 2016
@sebastianfeldmann sebastianfeldmann self-assigned this Feb 8, 2016
@sebastianfeldmann
Copy link
Owner

@sebastianfeldmann sebastianfeldmann commented Feb 8, 2016

Fixed in version 3.0.1, once again thanks for reporting this.

@sebastianfeldmann
Copy link
Owner

@sebastianfeldmann sebastianfeldmann commented Feb 8, 2016

To make sure everything (backup, check, crypt, sync and cleanup) worked you still have to use $result->allOk()
The method $result->wasSuccessful() is still limited to the backup and it's checks.

@sebastiaanluca
Copy link
Author

@sebastiaanluca sebastiaanluca commented Feb 9, 2016

You're too good! Thanks man :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.