The command can be used to validate an input --config and throw
warnings and errors.
Add a new argument strctErrors to the functions
documentMapTo{Init|Join}Configuration(). This allows
to return errors from the calls to VerifyUnmarshalStrict().
Add a new function verifyKnownGVKs() in config/common.go
that is used to verify if a list of GVKs in a config file is
known. This function is used by the "validate" and "migrate"
commands.
Both commands now throw errors for unknown APIs or fields.
* Add warning log callback in client-go loading rules
This provides a way to consumers use their own custom warning
mechanisms instead default klog warning.
* Use typed error instead plain string
* Fix interface change in unit test
The setting for garbagecollector was added 7 years ago in 9ac91e5172 for
"debugging gc". graph_builder was added 6 years in a98801c1 when restoring the
-vmodule parameter after some temporary removal, without an explanation.
It seems safe to assume that the garbage collector has been debugged
sufficiently...
These defaults cause performance overhead:
- Enabling -vmodule slows down all log calls because checking verbosity
cannot take a simpler fast path.
- The amount of log output is much higher for those files.
The amount of log data also caused test output to get truncated, removing the
actual test failure explanation.
* Preserve code blocks in templates.Normalizer
Currently, if templates.LongDesc function is invoked multiple times
for a string including a code block, this code block is converted to
invalid code block.
The reason of this issue is that blackfriday package, which templates package uses, relies on
4 * indentation to detect code blocks. This PR always preserves
4 * indentation in code blocks to always detect it code blocks in also
post invocations.
* Add indentations to test for code blocks
* Use strings.repeat for repetition
Move the Linux-specific conntrack setup code into a new
"platformSetup" rather than trying to fit it into the generic setup
code.
Also move metrics registration there.
Applying it to the entire spec included cleaning up, which makes predicting the
acceptable duration harder because it includes code not owned by the test
itself. It's better to specify a timeout only for the test code itself.
Previously it would corrupt the log when it ran stuff like:
go mod tidy >> "${LOG_FILE}" 2>&1
because this would reopen the file. Also, if that failed, the `finish`
function would be called ALSO with output to the log.
Now we let &1 and &2 always be the log, and &11 and &22 are the real
stdout/stderr, which means we have to say that explicitly when we want
output.
No, I cannot do `OUT="&11"` - I would have to use `eval` to make that
work.
