Will not include go module references — for now — as this might well break downstream projects that consume ytt as a library.

Maybe we could also summarize and discuss the expected behavior (along with explanations for those decisions) with regard to # and ytt, in all of its permutations? That is:

# We consider this ambiguous. Did you mean to comment only visible in ytt, emit it in output YAML or miss an @? To ignore (and treat as a ytt comment, pass --ignore-unknown-comments)
#Same as above. Note the lack of space.
## Explicitly intended to be emitted in resulting YAML output (pending issue #63)
#! Explicitly intended to be a comment only visible in ytt.
#@ Explicitly intended for ytt directives

The above is just an example of the expectations, of course. I know that sort of guidance would help me a lot in understanding what ytt expects of me when passing code to it. Once settled, it'd be great to have that somewhere easily visible in documentation early on somehow so it's easier to understand.

Excellent suggestions, @patricknelson; thank you.

Yeah, a straight-forward authoring guide seems in order. A key (and prominent) section would handle exactly this notation.

I presume we'd expect a similar failure scenario as in in @davedittrich's use case as well (e.g. #cloud-config), not just hash-spaces, correct?

Absolutely — in effect, when a YAML file becomes a yaml-template, ytt is taking over the commenting "space" in that document. Any data in that space that isn't recognized by ytt is a potential template coding error.

It appears this has morphed from being "Support standard YAML comments" (I suppose treating # Comment as #! Comment without erroring) into how to treat an entire file (e.g. yaml-plain vs yaml-template).

Yeah, that shift happened. There are a number of use-cases we're solving for simultaneously. In an attempt to keep things as simple as possible, we're chunking down for a more fundamental shift to try to accommodate as many as we can.

For me, my 95% use case will be yaml-template where the full file (or pipe) is originally intended for ytt, so the allowance of # Comment is simply a succinct syntactic sugar that has the side effect of also working normally on plain non-ytt formatted YAML code (be it just a segment of plain YAML or an entire file, a.k.a. yaml-plain).

We hear and appreciate that the original request was asking for allowing YAML comments in ytt templates. We'd love to be able to treat these inputs this way. However, as detailed above, allowing for such comments (unfortunately) also has the side effect of allowing for subtle template code errors (best illustration is where there's a lot of annotations and just one line or another is missing the meta-character: the result is that one line is quietly not executed).

It's hard not to see how when the tool does support plain YAML and that there's a notation for commenting in templates that it's reasonable to require authors to use that notation. It's legit possible we're missing something — if so, please help us understand.

That is, being less "safe" by default but still retaining linting capability by adding a new --use-strict-comments flag (and/or similar file marker).

Being less safe by default is an anti-goal for this project. This recent discussion has been all about how to retain that characteristic while improving the UX around widely held needs (namely, flowing plain YAML through the tool).

Of course, this would be a non-backward compatible change due to the change in default behavior and how it'd affect developer workflows.

It's hard to exaggerate the costs of breaking changes. We'd really want to be making a sweeping improvement that benefits the vast majority of our community to do so.

Sweeping up: #22 made it into v0.13.0; removing "in-progress" label.

@knight42 will you be able to attend next week's SIG-CLI call or record a demo and I'll re-play that during the call?

@bboreham: This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

<details>

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. </details>

The member GracePeriodSeconds defaults to 0, which is interpreted as "delete immediately" by the lower layers called. I'm not sure whether this is a bug or some subtle design I haven't figure out.

IMHO it would have been better to copy metav1.DeleteOptions which makes GracePeriodSeconds a pointer, so the default value is nil.

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale

@vdemeester @pradeepitm12 Can you guys review this PR it's been pending since 6 days now?

@danielhelfand @pradeepitm12 Can you guys review this PR it's been pending since 6 days now?

@danielhelfand @pradeepitm12 Can you guys review this PR it's been pending since 6 days now?

@pradeepitm12 @piyush-garg Can you review this and give lgtm so this PR can merge?

@soltysh Hi! I have almost implemented this interesting feature, it is not that hard as I expected.

/remove-lifecycle rotten

hmm, i was pretty sure harbor support manifest lists. is it an older version of harbor?

your alternative would be to look at manifest list, identify specific image (the one that makes sense for your platform) and then reference that instead of referencing to the manifest list.

@adriens sounds interesting. tell us more about what you thinking? (im not too familiar with java world workflows)

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with /close.

/lifecycle stale

Send feedback to tektoncd/plumbing.

@fejta-bot: Closing this issue.

<details>

In response to this:

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. </details>

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks!

If the matter is security related, please disclose it privately via https://kubernetes.io/security/ -->

What happened: Like this comment said: https://github.com/kubernetes/kubernetes/pull/91372#issuecomment-633467779

What you expected to happen: Find a way to honor both --user in clusterrolebinding and global --user flag.

How to reproduce it (as minimally and precisely as possible): <!-- Please make sure you are able to reproduce the bug using a supported version and version skew of Kubernetes. See https://kubernetes.io/docs/setup/release/version-skew-policy for which versions and are currently supported. -->

Anything else we need to know?:

Environment:

• Kubernetes client and server versions (use kubectl version):
• Cloud provider or hardware configuration:
• OS (e.g: cat /etc/os-release):