chore: ease maintenance of upcoming parser #118#189
Conversation
Codecov Report
@@ Coverage Diff @@
## develop #189 +/- ##
===========================================
+ Coverage 99.20% 99.59% +0.39%
===========================================
Files 64 64
Lines 2505 2468 -37
Branches 113 108 -5
===========================================
- Hits 2485 2458 -27
+ Misses 14 8 -6
+ Partials 6 2 -4
Continue to review full report at Codecov.
|
d451d47 to
64f3261
Compare
Codecov Report
@@ Coverage Diff @@
## develop #189 +/- ##
===========================================
+ Coverage 99.20% 99.87% +0.67%
===========================================
Files 64 65 +1
Lines 2505 2451 -54
Branches 113 108 -5
===========================================
- Hits 2485 2448 -37
+ Misses 14 3 -11
+ Partials 6 0 -6
Continue to review full report at Codecov.
|
|
@cakepietoast ready when you are -- this is mostly semantics to ease maintenance after publishing the parser utility -- Could you take a look and see if the docstrings, import system, etc. are to what you'd expect too? The additional |
|
Next steps before 1.7.0:
|
Co-authored-by: Joris Conijn <jco@woodwing.com>
to-mc
left a comment
There was a problem hiding this comment.
LGTM - with the sole suggestion of renaming the parser function!
Issue #, if available: #118
Description of changes:
Minor internal changes to ensure consistency across utilities, and ease maintenance before we write docs.
Checklist
detailtypewas the only odd one out but I'll double check if there are others_parsevalidatorenvelope utilityenvelope.<event_source>.parserfunction with the same functionality the decoratorBreaking change checklist
RFC issue #:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.