fix: print engine.Render() result on debug level

[dmmordvi]

Summary by Bito

• Replaced a single TraceStruct log for rendered templates with a loop that selectively logs individual file contents at Debug level.
• Added conditions to skip logging files that start with '_', end with NotesFileSuffix, or are empty after trimming.
• Changed logging from tracing the entire renderedTemplates struct to detailed logging of qualifying template contents.

[ilya-lesikov]

I wonder, do we add any filepath in a comment on the first line of the resulting yaml?

With helm templates we add a comment like this:

---
# Source: testchart/templates/test.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  annotations: {}
  labels: {}

Can we add at least something like an entrypoint name? Either a bundle.js path or an entrypoint path (what is it, index.js, index.ts?). For backwards compatibility.

Actually I see now that there is a map with filepaths returned. Just make sure that at some point the paths are added as comments like this ^^

[dmmordvi]

@ilya-lesikov We don't add comment # Source: ..., but print debug message like Rendered content of "testchart/templates/test.yaml": <yaml content from new line>. Should i use comment instead separate message?

[dmmordvi]

For JS/TS we print entrypoint file name (testchart/ts/src/index.ts / testchart/ts/src/index.js) or bundle file path (if there is no entrypoint). But it is still in progress on #565

[ilya-lesikov]

A separate message is needed anyways. But we also need in commands like nelm chart render or in manifests saved in the release filename as a comment on the first line of the manifest, like we do now with helm templated manifests.

And I'd like it to be the actual filename from where it's sourced. If that's a bundle.js then bundle.js, if that's index.ts or index.js (for runtime dependency resolution), then it's that.

[ilya-lesikov]

just always print it once on line 236, it's just a debug message, don't bother much. Even if no templates.

And using once for it while possible, probably not very idiomatic in Go. If ever needed something like this, better do it without once (via for i loop, or some other way)