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

LinchpinAPI do_validation is always returning rc 0 even though validation fails on layout #1578

Closed
Dannyb48 opened this issue Jan 17, 2020 · 2 comments · Fixed by #1639
Closed
Assignees
Labels
Milestone

Comments

@Dannyb48
Copy link
Contributor

Describe the bug
When calling the LinchpinAPI do_validation function, it returns a tuple containing the return code, and the results of the validation. The do_validation always returns 'successful' because the rc is 0 but it's not until you run do_action, where it does another validation and throws a ValidationException error on the layout fields.

Looks like do_validation calls validator function validate_pretty, where as do_action is calling validate. In validate_pretty the only time the return code is changed to non-zero is if topology validation fails but not if layout or cfgs validation fails. validate_pretty should be returning non-zero for all schema key failures.

To Reproduce
Unfortunately this won't be reproduceable through the CLI because the shell __ini__.py doesn't even use the return code to detect failure, it uses the actual results data, and does a string check for certain key indicators.

Steps to reproduce the behavior:

  1. Create a pinfile with improper layout schema
  2. Open python console
  3. Import json, LinchpinAPI, LinchpinContext modules
  4. Use json module to load the pinfile data
  5. Intialize a LinchpinAPI with a LinchpinContext
  6. Provide the pinfile dict to the LinchpinAPI.do_validation()
  7. Inspect that rc is 0 but results shows error in layout

Expected behavior
If layout is specified in the pinfile and do_validation fails due to improper layout schema it should return a non-zero rc code.

@Dannyb48 Dannyb48 added the bug label Jan 17, 2020
@Dannyb48 Dannyb48 self-assigned this Jan 21, 2020
@samvarankashyap
Copy link
Contributor

@Dannyb48 Any update on this?
We will be moving it to the next sprint until it is fixed.

@Dannyb48
Copy link
Contributor Author

Dannyb48 commented Feb 4, 2020

I will be working on it this current sprint.

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

Successfully merging a pull request may close this issue.

2 participants