The `listAll` function returned a slice where all pointers referred to the same
instance. That instance had the value of the last list entry. As a result, unit
tests only compared that element.
During the reserve phase, the first claim gets reserved in two test
cases. Those two tests must expect that change. That hadn't been noticed before
because that first claim didn't get compared.
the e2e framwork use active loops to wait for certain async operations,
these loops need to retry on some operations and fail in others.
For the functions that depend on some operations to happen, the
apiserver may return 503 errors until that specific service is
available, so we should retry on those too.
Change-Id: Ib3d194184f6385b9d3d151c7055f27c97c21c3ff
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