Support Warning header aggregation and reporting in crane#1604
Support Warning header aggregation and reporting in crane#1604imjasonh merged 5 commits intogoogle:mainfrom
Warning header aggregation and reporting in crane#1604Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1604 +/- ##
==========================================
- Coverage 72.80% 72.74% -0.07%
==========================================
Files 118 118
Lines 9440 9452 +12
==========================================
+ Hits 6873 6876 +3
- Misses 1869 1878 +9
Partials 698 698 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Warning header aggregation and reportingWarning header aggregation and reporting in crane
|
I think there are a couple ways we could go with this that will be slightly better than adding We already have There's also I really dislike the There's also the How do you feel about this not being a public API, and instead we have crane pass in a custom transport that does all these warncollectory things until we have a happier public interface? |
I'm fine with that. I'll get something along these lines up shortly. |
opencontainers/distribution-spec#393 seems to be on a good path, so I figured I'd put in a better implementation of warning collection/reporting in ggcr.
registry.WithWarningtopkg/registrythat probabilistically reports the given warning (WithWarning(0.1, "hi")warns"hi" 10% of the time)This also updates
cmd/registryto add demo warnings some % of the time; I'll probably revert this before merging, this is just for demo purposes. Speaking of demo:Logic for parsing the warning message out of the header is pretty janky, and could use some tests.
Clients that use go-containerregistry won't suddenly start reporting warnings without changes. They'll need to inject a transport like
cranedoes -- if we thinkcrane's approach is generally useful we can make it available inpkg/craneitself.