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

Separate exit code for test parsing errors? #317

Closed
Hoodoo opened this issue Feb 15, 2018 · 5 comments · Fixed by #814
Closed

Separate exit code for test parsing errors? #317

Hoodoo opened this issue Feb 15, 2018 · 5 comments · Fixed by #814

Comments

@Hoodoo
Copy link

Hoodoo commented Feb 15, 2018

Thanks for all the hard work on this utility, I've found it really easy to use.

I use a simple bash script to run tests depending on different facter facts on hosts. However, I'd like to be able to tell failing tests from synctactically incorrect tests, e.g.:

#============ The test which should fail:
lan1:~ # cat goss_incorrect.yaml
port:
  tcp:22:
listening: false

lan1:~ # goss --gossfile goss_incorrect.yaml validate -f tap
Error: Could not parse resource Port:tcp:22

lan1:~ # echo $?
1

#============ The incorrect test:
lan1:~ # cat goss_failing.yaml 
port:
  tcp:22:
    listening: false

lan1:~ # goss --gossfile goss_failing.yaml validate -f tap
1..1
not ok 1 - Port: tcp:22: listening: doesn't match, expect: [false] found: [true]

lan1:~ # echo $?
1

I believe having a separate exit code for YAML parsing/template rendering would make scripting easier.

@kwaio
Copy link

kwaio commented Mar 12, 2018

I was looking for documentation/code that would explain the different possible error values... and this proves that's no specific policy.
I would love to have different error codes to process whether there was gossfile errors or validation errors. (wish I had any Go skill to suggest a PR)

@aelsabbahy
Copy link
Member

Agree, this would be useful for scripting.

@kevinreddot
Copy link

kevinreddot commented Jun 28, 2018

I was looking for documentation/code that would explain the different possible error values... and this proves that's no specific policy.

It is. E.g., FreeBSD documents it in sysexits man page, Linux has /usr/include/sysexits.h too. In Go there is https://godoc.org/sny.no/os/sysexit.

So, for incorrect yaml the proper exit code would probably be EX_CONFIG while failed test could still be 1.

@naftulikay
Copy link
Contributor

I'm also affected by this. I maintain the degoss Ansible role (which installs, runs, and removes Goss and test cases on a machine), and I have to write some very interesting logic to catch these kinds of errors. Goss returns 0 as a return code when it fails to load or parse the Goss file.

My workaround is to set --format to json and if I'm unable to deserialize JSON, I assume that there's an error, regardless of return code.

@marcinpraczko
Copy link

marcinpraczko commented Aug 8, 2019

I would say that this is also importnat for check over HTTP?
As I can see goss returns proper result (HTTP BODY) with errors - but then returns 503 as HTTP return code.
So is really hard to know if connection with goss failed or whether checks failed:

http http://goss.zone/healthz
HTTP/1.1 503 Service Unavailable   # !!!! <- 503 - which is not correct - service IS working, checks fails.
Content-Length: 1289
Content-Type: text/plain; charset=utf-8
Date: Thu, 08 Aug 2019 10:31:29 GMT

GOSS CRITICAL - Count: 60, Failed: 9, Skipped: 0, Duration: 0.219s

aelsabbahy added a commit that referenced this issue Jun 24, 2023
@aelsabbahy aelsabbahy mentioned this issue Jun 25, 2023
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants