Closed C0urante closed 5 years ago
@issmirnov enjoying this project so far, thought this change might be useful. Looking forward to hearing what you think!
@C0urante Thank you, really excited to get this PR. I've fixed travis to build PR's now, so we should get some more data after the next push.
Merging #31 into master will increase coverage by
2.4%
. The diff coverage is100%
.
@@ Coverage Diff @@
## master #31 +/- ##
=========================================
+ Coverage 49.77% 52.17% +2.4%
=========================================
Files 4 4
Lines 219 230 +11
=========================================
+ Hits 109 120 +11
Misses 103 103
Partials 7 7
Impacted Files | Coverage Δ | |
---|---|---|
config.go | 32.92% <ø> (ø) |
:arrow_up: |
text.go | 83.33% <100%> (+3.33%) |
:arrow_up: |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact)
,ø = not affected
,? = missing data
Powered by Codecov. Last update 7aaf69d...057a69f. Read the comment docs.
@C0urante Fantastic work, thank you very much for a great addition!
Had to fight a few bugs with goreleaser, but ultimately got the release up. Homebrew cask has been updated as well at https://github.com/issmirnov/homebrew-apps/commit/3b33e0b78edcf4c6c026af78fd6ec326c3be4ec7
Most URL patterns behave nicely with Zap as-is, but there are a few exceptions. One gap I've encountered is with URLS that embed version numbers as path elements; for example, the Apache Kafka docs use the major and minor version number concatenated (with no dot delimiter) as their first path element and each version of their docs so far has followed the same pattern for where javadocs, quickstarts, configuration docs, etc. are found. I've had to install several redundant redirects in my Zap config to work with this:
However, that's clearly a workaround and it'd be nice if Zap recognized URL patterns like this natively. As a light first pass at addressing this issue, I'd like to propose that the special path of
"*"
be allowed to match any path element that isn't explicitly matched in the config file. Should this match occur, the path element will then be kept as-is, but also allow for expansion of the remaining path elements. An example is included in the README, and a few tests are added that should also help demonstrate the intended functionality. To put things into context, the above config snippet could now be reduced to: