Add documentation to k6 exit codes definitions

[oleiade]

What?

This Pull Request adds Godoc documentation comment to k6 exit codes.

I've added my context, but if reviewers have more about specific exit codes they wish to add, that would be the perfect opportunity.

Why?

Having recently been in the situation of interpreting the status code (on-call) for debugging purposes, I found that in some instances, the reason and context for each status code could have been more straightforward. Hence, I added documentation to each of them, albeit probably not complete and not having as much context as possible.

Checklist

• I have performed a self-review of my code.
• I have added tests for my changes.
• I have run linter locally (make ci-like-lint) and all checks pass.
• I have run tests locally (make tests) and all tests pass.
• I have commented on my code, particularly in hard-to-understand areas.

Related PR(s)/Issue(s)

[olegbespalov]

Great stuff ❤️ Thanks for doing this 🙇

To be more precise, one possible improvement could be to explicitly name k6's REST API in the places where it's mentioned. What do you think?

[oleiade]

I'm sorry, I'm not sure to understand what you're suggesting. What changes do you have in mind? 🙇🏻

[olegbespalov]

@oleiade I've added direct suggestion feel free to accept or drop them

[imiric]

Save for a couple of cases like ExternalAbort, most of these comments seem redundant to me, as they repeat in prose what is already self-explained by the constant names. But if you and others find this helpful, I'm not against it.

[olegbespalov]

@imiric they might seem redundant, but in fact, such comments also help go documentation properly parse and put such constants into the proper place. E.g. right now the section is empty https://pkg.go.dev/go.k6.io/[email protected]/errext/exitcodes#pkg-constants

For sure the consts themself, are still presented and self-explanatory, but they also provide a better UX with a bit of cost.

[oleiade]

I agree that they might come up as redundant, but they're actually the result of me struggling to match k6 exit codes to their meaning "easily".

I'd still like to merge them, and eventually even improve them 👍

[codecov-commenter]

Codecov Report

Patch coverage: 67.00% and project coverage change: +0.27% 🎉

Comparison is base (5f5e374) 72.85% compared to head (11215c6) 73.13%.
Report is 66 commits behind head on master.

❗ Current head 11215c6 differs from pull request most recent head 8bab212. Consider uploading reports for the commit 8bab212 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3200      +/-   ##
==========================================
+ Coverage   72.85%   73.13%   +0.27%     
==========================================
  Files         256      256              
  Lines       19804    19890      +86     
==========================================
+ Hits        14429    14546     +117     
+ Misses       4474     4414      -60     
- Partials      901      930      +29     

Flag	Coverage Δ
ubuntu	73.13% <67.00%> (+0.33%)	⬆️
windows	?

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Changed	Coverage Δ
api/v1/setup_teardown_routes.go	55.55% <0.00%> (-3.27%)	⬇️
js/jsmodules.go	100.00% <ø> (ø)
js/modules/k6/experimental/tracing/propagator.go	100.00% <ø> (ø)
lib/consts/consts.go	78.57% <ø> (ø)
lib/executors.go	93.10% <ø> (ø)
metrics/engine/ingester.go	91.48% <ø> (ø)
output/cloud/expv2/collect.go	92.59% <ø> (+0.51%)	⬆️
output/cloud/v1/output.go	57.45% <0.00%> (-10.36%)	⬇️
cloudapi/insights/client.go	62.20% <12.50%> (-17.18%)	⬇️
js/modules/k6/experimental/tracing/module.go	69.09% <50.00%> (-2.61%)	⬇️
... and 17 more

... and 10 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mstoykov]

I have the same opinion as @imiric, but I guess if others find it useful -let's do it.