Fix validate sub-command after normalizer failure#352
Fix validate sub-command after normalizer failure#352guilliamxavier wants to merge 5 commits intoergebnis:masterfrom guilliamxavier:patch-2
Conversation
to work around Composer bug(s) in combination with --no-check-lock/--no-check-publish
|
Note: The order of commits isn't completely logical. Here's a better recap (omitting static analysis noise):
Do you want me to reorder and force-push? Update: done (see below) |
Codecov Report
@@ Coverage Diff @@
## master #352 +/- ##
============================================
- Coverage 87.43% 86.50% -0.94%
- Complexity 38 40 +2
============================================
Files 4 4
Lines 191 200 +9
============================================
+ Hits 167 173 +6
- Misses 24 27 +3
Continue to review full report at Codecov.
|
Currently "publish errors" *are* schema violations (missing required properties or unknown additional properties)
(even in the case where composer validate would return 0 or 2)
|
Heads-up: I went ahead and reordered the commits as proposed (and squashed static analysis noise into the corresponding commit). But now some checks are failing:
|
|
Apologies again for the delay - I've started work on this, as I have had a few ideas around it! I'll keep you posted! 🤓 |
|
Thank you for your contribution, but I have taken a different approach in #416. |
This PR
--strictoption from the post-failure call tovalidate, to avoidvalidatecommand: with--no-check-publish, adding--strictmakes warnings disappear from output composer/composer#8602 (and its linked issues)--no-check-publishoption from the post-failure call tovalidate, because "publish errors" are (strict) schema violationsnormalizecommand returns1rather than0or2when it failed because of schema errorsRelated to #349 (part of; doesn't address the question of relaxing validation in the normalizer).
Related to #25.