Closed catdevman closed 1 month ago
@aelsabbahy any suggestions on how to get the current version of goss down into the NewDefHTTP function?
Apologies, somehow I've completely missed this.
I will review over the weekend and get back to you.
To answer your question on version, it's currently here:
https://github.com/goss-org/goss/blob/ab2f627b385d3e4414490f9e13954004aff03651/cmd/goss/goss.go#L21
https://github.com/goss-org/goss/blob/62a9743aa04e950b205d742c6024c7ab727fd6f1/release-build.sh#L25
Perhaps moving it to a shared version pkg and having both main and this import the shared pkg/var. If there's a better way, feel free to suggest it.
@aelsabbahy I thought about this a little bit and since the util package is already included in the http code perhaps it might make sense to add it there. I didn't change how main.version was getting set, instead I just added to that process. I tested by making a goss file that called an "echo server" that spat out whatever headers got sent. I am not sure of the best way to test this... maybe integrating with a service like https://echo.free.beeceptor.com/ or spinning up an "echo server" to test against within the pipeline? or maybe this doesn't need tested? Let me know what you're thinking.
CI failed due to linting issues:
invalid gofmt:
cmd/goss/goss.go
make: *** [Makefile:49: fmt] Error 1
https://app.travis-ci.com/github/goss-org/goss/jobs/621547789#L307
Yeah I shouldn't be surprised I tried editing it through GitHub because I wasn't at a computer. 🤦♂️
Yeah I shouldn't be surprised I tried editing it through GitHub because I wasn't at a computer. 🤦♂️
You will receive zero judgement from me, been there 😅
@aelsabbahy I know it was just because of whatever character was in there but it does crack me up a little bit that in that last run Windows was like "looks good to me brother" and mac and linux are saying "hold on a moment something is not quite right" :laughing:
Once the test is in place, this PR is ready to merge.
Noticed the test was removed so waiting on merging it.
Well I was trying to figure out why Linux was failing but perhaps that is expected behavior in the pipeline?
No problem, I added the test back. The issue is httpbin returns the headers as pascal case but the goss.yaml was lowercase so it wasn't matching.
@aelsabbahy ah I believe that's a different error then I was getting locally or perhaps what I was getting just didn't make sense for it to be this error. Either way glad to see it merged and happy to have been of service. I've never gotten to use goss professionally but I always thought it was a brilliant bit of tech.
Curious, do you use it for personal projects? If so, what's your primary use-case?
Always fun learning how others are using Goss.
Fun note, after initially releasing Goss, I didn't use it personally or professionally for 1-2 years.
I've not found a personal use. I worked in DevOps for a while and I was going to use it for health checks and maybe even regression test for a rest API but they hired a test engineer and he scrapped that for his own thing that did exactly what goss does but it took him 6 months to just get started in it. Then I left right as the whole software division closed up. That was the closest I got. But I have some new ideas and I think eventually these projects could benefit from goss. Mostly as a way of regression testing. Essentially boot up a golden DB and test if the responses have that is expected in them.
Checklist
make test-all
(UNIX) passes. CI will also test thisDescription of change
Close #882. Adding default user-agent header by detecting if a user-agent header was given in the
request_headers
field in the goss file and defaulting togoss/x.x.x
. Any guidance that can be given on how to get the current version of goss within the codebase would be appreciated. I saw app.Version but that seemed to be related to urfave/cli so wasn't sure I could get that from that far down. The easiest way is probably adding it to the context but I didn't want to bloat that since it would go to all checks not just http.