The "message" attribute is redundant. Adding line breaks ensures that the curly
brackets used by Prow are on separate lines.
Before:
{Script Error ScriptError test/e2e/e2e.go:437:5: var `unused` is unused (unused)
var unused = 1 // intentionally trigger a golangci-lint warning.
^}
After:
{ScriptError
test/e2e/e2e.go:437:5: var `unused` is unused (unused)
var unused = 1 // intentionally trigger a golangci-lint warning.
^
}
When sh2ju.sh was called to generate the junit_verify.xml, it used to include
the entire output of a failed script twice: once as failure message, once as
log output.
This output can be large and often the actual failure isn't near the top, but
rather at the end or (in the case of the different golangci-lint invocations)
embedded in the log. This makes them hard to see at a glance when looking at
the Prow result page for a job.
Now a verify script can prefix relevant lines with "ERROR: " and then only
those lines are used as failure message in JUnit, without that prefix.
That string was chosen because Prow itself also then picks up those lines when
viewing the entire build log and it is unlikely that some script prints such
lines when they are not meant to be part of the failure.
If some script outputs no such lines, "see stderr for details" is used as
failure message. This is better than before because it avoids the redundancy.
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
