More consistent helm charts labels

For #52034
This PR adds the following labels to almost all resources:

app.kubernetes.io/name
app.kubernetes.io/instance
app.kubernetes.io/part-of
app.kubernetes.io/version
app.kubernetes.io/managed-by
helm.sh/chart

The app.kubernetes.io/name is not part of the template because it varies across charts.
The only exceptions are autogenerated templates like manifests/charts/istiod-remote/templates/crd-all.gen.yaml.
This PR only add labels.
I tested this by writing a small script that compared the generated manifests with istioctl master and istioctl from my current branch with profiles ambient, demo, and default.
Also, if the app label is defined, the app.kubernetes.io/name label will match.
If there is no app label, then I made an educated guess as to what app.kubernetes.io/name should be (usually istiod), but this is my last big question.

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

@bleggett I would appreciate some feedback to see if I am going in the right direction.

/test all

@Stevenjin8: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio
1d8a4a8b2b43c1a9dabeb31987c61ed21e869c54
link
true
/test release-notes

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-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio
1d8a4a8b2b43c1a9dabeb31987c61ed21e869c54
link
true
/test release-notes

gencheck_istio
1d8a4a8b2b43c1a9dabeb31987c61ed21e869c54
link
true
/test gencheck

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-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio
1d8a4a8b2b43c1a9dabeb31987c61ed21e869c54
link
true
/test release-notes

gencheck_istio
1d8a4a8b2b43c1a9dabeb31987c61ed21e869c54
link
true
/test gencheck

integ-distroless_istio
1d8a4a8b2b43c1a9dabeb31987c61ed21e869c54
link
true
/test integ-distroless

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-sigs/prow repository. I understand the commands that are listed here.

@bleggett @ilrudie Have applied new labels, but want to double check that I am on the right track (and a few questions)

.Release.XXX props are only set during helm install because they are install-time variables (which makes sense).
So if you just do helm template the values will be unset (unless you do helm template --release-name MyRelease of course - all the Helm install-time vars are stubbable with template args if you want).
I'm not wedded to the guards since the labels should always be there no matter what, and if they are empty because you (or your install tool) didn't set install-time variables, then they should be empty.
I'll defer to @ilrudie tho, he had an opinion on this IIRC.

I added the conditions specifically because istioctl was failing without them. A potential solution as Ben mentioned would just be to populate that stuff in istioctl and if that is what folks want to do then go for it. I'm not nearly as opinionated about them strictly always needing to exist to ignoring those labels in contexts outside of helm install seemed fine to me.

.Release.XXX props are only set during helm install because they are install-time variables (which makes sense).
So if you just do helm template the values will be unset (unless you do helm template --release-name MyRelease of course - all the Helm install-time vars are stubbable with template args if you want).
I'm not wedded to the guards since the labels should always be there no matter what, and if they are empty because you (or your install tool) didn't set install-time variables, then they should be empty.
I'll defer to @ilrudie tho, he had an opinion on this IIRC.

I added the conditions specifically because istioctl was failing without them. A potential solution as Ben mentioned would just be to populate that stuff in istioctl and if that is what folks want to do then go for it. I'm not nearly as opinionated about them strictly always needing to exist to ignoring those labels in contexts outside of helm install seemed fine to me.

It seems like istioctl is just a Helm wrapper at this point, which (as far as I've tested) means that all the fields get auto populated.

@bleggett Any thoughts of the Cue OpenAPI generated files? So far, it seems like that only way to add change the labels is to update the protobuf files in istio/api with the new labels. But that feels against the spirit of this PR since we would just be copy pasting. I can't find a way to integrate Cue with Helm templating and vv. Probably because they are both templating engines.

@bleggett Any thoughts of the Cue OpenAPI generated files? So far, it seems like that only way to add change the labels is to update the protobuf files in istio/api with the new labels. But that feels against the spirit of this PR since we would just be copy pasting. I can't find a way to integrate Cue with Helm templating and vv. Probably because they are both templating engines.
My gut tells me to just ignore them for now, but that also feels against the spirit of this PR.

You mean this stuff? operator/pkg/apis/istio/v1alpha1/values_types.proto

Yeah - having to update those proto files every time we change helm values is a chore, and IMO a somewhat pointless use of protobufs. But I would just leave that for now - that's an istio-and-istioctl specific quirk and we have talked about dropping that, which would be better as a separate PR.

@bleggett Any thoughts of the Cue OpenAPI generated files? So far, it seems like that only way to add change the labels is to update the protobuf files in istio/api with the new labels. But that feels against the spirit of this PR since we would just be copy pasting. I can't find a way to integrate Cue with Helm templating and vv. Probably because they are both templating engines.
My gut tells me to just ignore them for now, but that also feels against the spirit of this PR.

It I remove the check for release.service then the template just fails to work and I'm missing helpful labels so I'm not sure that it is fixed although John is working on revising how installations in istioctl works so maybe that will address it. https://github.com/istio/istio/pull/52541

.Release.XXX props are only set during helm install because they are install-time variables (which makes sense).
So if you just do helm template the values will be unset (unless you do helm template --release-name MyRelease of course - all the Helm install-time vars are stubbable with template args if you want).
I'm not wedded to the guards since the labels should always be there no matter what, and if they are empty because you (or your install tool) didn't set install-time variables, then they should be empty.
I'll defer to @ilrudie tho, he had an opinion on this IIRC.

I added the conditions specifically because istioctl was failing without them. A potential solution as Ben mentioned would just be to populate that stuff in istioctl and if that is what folks want to do then go for it. I'm not nearly as opinionated about them strictly always needing to exist to ignoring those labels in contexts outside of helm install seemed fine to me.

It seems like istioctl is just a Helm wrapper at this point, which (as far as I've tested) means that all the fields get auto populated. This might be confusing though, because then you get labels like app.kubernetes.io/managed-by: Helm when you install with istioctl. I think the solution is to override these values in istioctl so that is shows something like app.kubernetes.io/managed-by: istioctl. Thoughts?

Without those guards the labels don't get templated/added correctly during istioctl install because release.service isn't popuilated. AFAIK it hasn't been fixed yet.

It seems like istioctl is just a Helm wrapper at this point

Yeah - it's sorta that but not entirely so ATM, and we have bugs (and PRs) open to (hopefully) make this a true statement.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

gencheck_istio
1d8a4a8b2b43c1a9dabeb31987c61ed21e869c54
link
true
/test gencheck

integ-distroless_istio
1d8a4a8b2b43c1a9dabeb31987c61ed21e869c54
link
true
/test integ-distroless

release-notes_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test release-notes

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-sigs/prow repository. I understand the commands that are listed here.

@bleggett @ilrudie Do we have any thoughts on having the helm.sh tags even though these charts could be used outside of helm? I feel like deleting it to avoid confusion, but I'm not super familiar with the installation mode landscape.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-distroless_istio
1d8a4a8b2b43c1a9dabeb31987c61ed21e869c54
link
true
/test integ-distroless

release-notes_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test release-notes

integ-helm_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test integ-helm

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-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-distroless_istio
1d8a4a8b2b43c1a9dabeb31987c61ed21e869c54
link
true
/test integ-distroless

release-notes_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test release-notes

integ-helm_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test integ-helm

unit-tests-arm64_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test unit-tests-arm64

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-sigs/prow repository. I understand the commands that are listed here.

@bleggett @ilrudie Do we have any thoughts on having the helm.sh tags even though these charts could be used outside of helm? I feel like deleting it to avoid confusion, but I'm not super familiar with the installation mode landscape.

I'd say leave it. We don't really need to be ashamed or hide that istioctl is based on helm templating IMO. We could also just gate it with a check if we want and only apply them when release.service is helm

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test release-notes

integ-helm_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test integ-helm

unit-tests-arm64_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test unit-tests-arm64

integ-telemetry-discovery_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test integ-telemetry-discovery

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-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test release-notes

integ-helm_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test integ-helm

unit-tests-arm64_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test unit-tests-arm64

integ-telemetry-discovery_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test integ-telemetry-discovery

unit-tests_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test unit-tests

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-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test release-notes

integ-helm_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test integ-helm

unit-tests-arm64_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test unit-tests-arm64

integ-telemetry-discovery_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test integ-telemetry-discovery

unit-tests_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test unit-tests

integ-telemetry_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test integ-telemetry

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-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test release-notes

integ-helm_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test integ-helm

unit-tests-arm64_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test unit-tests-arm64

integ-telemetry-discovery_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test integ-telemetry-discovery

unit-tests_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test unit-tests

integ-telemetry_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test integ-telemetry

integ-pilot-istiodremote_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test integ-pilot-istiodremote

integ-telemetry-istiodremote_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test integ-telemetry-istiodremote

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-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test release-notes

integ-helm_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test integ-helm

unit-tests-arm64_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test unit-tests-arm64

integ-telemetry-discovery_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test integ-telemetry-discovery

unit-tests_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test unit-tests

integ-telemetry_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test integ-telemetry

integ-pilot-istiodremote_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test integ-pilot-istiodremote

integ-telemetry-istiodremote_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test integ-telemetry-istiodremote

integ-pilot_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test integ-pilot

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-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

release-notes_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test release-notes

integ-helm_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test integ-helm

unit-tests-arm64_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test unit-tests-arm64

integ-telemetry-discovery_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test integ-telemetry-discovery

unit-tests_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test unit-tests

integ-telemetry_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test integ-telemetry

integ-pilot-istiodremote_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test integ-pilot-istiodremote

integ-telemetry-istiodremote_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test integ-telemetry-istiodremote

integ-pilot_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test integ-pilot

integ-cni_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test integ-cni

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-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-helm_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test integ-helm

unit-tests-arm64_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test unit-tests-arm64

integ-telemetry-discovery_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test integ-telemetry-discovery

unit-tests_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test unit-tests

integ-telemetry_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test integ-telemetry

integ-pilot-istiodremote_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test integ-pilot-istiodremote

integ-telemetry-istiodremote_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test integ-telemetry-istiodremote

integ-pilot_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test integ-pilot

integ-cni_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test integ-cni

release-notes_istio
72f8b4083aa5f406f201603a37425f8727c3df18
link
true
/test release-notes

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-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests-arm64_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test unit-tests-arm64

integ-telemetry_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test integ-telemetry

unit-tests_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test unit-tests

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-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-telemetry_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test integ-telemetry

unit-tests_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test unit-tests

unit-tests-arm64_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test unit-tests-arm64

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-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-telemetry_istio
bae2e0880f841bca5767dda192b4c77520d8aebd
link
true
/test integ-telemetry

unit-tests_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test unit-tests

unit-tests-arm64_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test unit-tests-arm64

integ-helm_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-helm

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-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test unit-tests

unit-tests-arm64_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test unit-tests-arm64

integ-helm_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-helm

integ-telemetry_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-telemetry

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-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test unit-tests

unit-tests-arm64_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test unit-tests-arm64

integ-helm_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-helm

integ-telemetry_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-telemetry

integ-telemetry-discovery_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-telemetry-discovery

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-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test unit-tests

unit-tests-arm64_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test unit-tests-arm64

integ-helm_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-helm

integ-telemetry_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-telemetry

integ-telemetry-discovery_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-telemetry-discovery

integ-pilot-istiodremote_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot-istiodremote

integ-pilot_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot

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-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test unit-tests

unit-tests-arm64_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test unit-tests-arm64

integ-helm_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-helm

integ-telemetry_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-telemetry

integ-telemetry-discovery_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-telemetry-discovery

integ-pilot-istiodremote_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot-istiodremote

integ-pilot_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot

integ-cni_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-cni

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-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test unit-tests

unit-tests-arm64_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test unit-tests-arm64

integ-helm_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-helm

integ-telemetry_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-telemetry

integ-telemetry-discovery_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-telemetry-discovery

integ-pilot-istiodremote_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot-istiodremote

integ-pilot_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot

integ-cni_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-cni

integ-telemetry-istiodremote_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-telemetry-istiodremote

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-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test unit-tests

unit-tests-arm64_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test unit-tests-arm64

integ-helm_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-helm

integ-telemetry_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-telemetry

integ-telemetry-discovery_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-telemetry-discovery

integ-pilot-istiodremote_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot-istiodremote

integ-pilot_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot

integ-cni_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-cni

integ-telemetry-istiodremote_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-telemetry-istiodremote

integ-telemetry-mc_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-telemetry-mc

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-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test unit-tests

unit-tests-arm64_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test unit-tests-arm64

integ-helm_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-helm

integ-telemetry_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-telemetry

integ-telemetry-discovery_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-telemetry-discovery

integ-pilot-istiodremote_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot-istiodremote

integ-pilot_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot

integ-cni_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-cni

integ-telemetry-istiodremote_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-telemetry-istiodremote

integ-telemetry-mc_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-telemetry-mc

integ-pilot-istiodremote-mc_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot-istiodremote-mc

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-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test unit-tests

unit-tests-arm64_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test unit-tests-arm64

integ-helm_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-helm

integ-telemetry_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-telemetry

integ-telemetry-discovery_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-telemetry-discovery

integ-pilot-istiodremote_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot-istiodremote

integ-pilot_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot

integ-cni_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-cni

integ-telemetry-istiodremote_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-telemetry-istiodremote

integ-telemetry-mc_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-telemetry-mc

integ-pilot-istiodremote-mc_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot-istiodremote-mc

integ-pilot-multicluster_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot-multicluster

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-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test unit-tests

unit-tests-arm64_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test unit-tests-arm64

integ-helm_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-helm

integ-telemetry_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-telemetry

integ-telemetry-discovery_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-telemetry-discovery

integ-pilot-istiodremote_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot-istiodremote

integ-pilot_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot

integ-cni_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-cni

integ-telemetry-istiodremote_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-telemetry-istiodremote

integ-telemetry-mc_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-telemetry-mc

integ-pilot-istiodremote-mc_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot-istiodremote-mc

integ-pilot-multicluster_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot-multicluster

integ-basic-arm64_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-basic-arm64

integ-ds_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-ds

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-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test unit-tests

unit-tests-arm64_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test unit-tests-arm64

integ-helm_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-helm

integ-telemetry_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-telemetry

integ-pilot-istiodremote_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot-istiodremote

integ-pilot_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot

integ-cni_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-cni

integ-telemetry-istiodremote_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-telemetry-istiodremote

integ-telemetry-mc_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-telemetry-mc

integ-pilot-istiodremote-mc_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot-istiodremote-mc

integ-pilot-multicluster_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot-multicluster

integ-basic-arm64_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-basic-arm64

integ-ds_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-ds

integ-telemetry-discovery_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry-discovery

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-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test unit-tests

unit-tests-arm64_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test unit-tests-arm64

integ-helm_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-helm

integ-telemetry_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-telemetry

integ-pilot-istiodremote_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot-istiodremote

integ-pilot_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot

integ-cni_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-cni

integ-telemetry-istiodremote_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-telemetry-istiodremote

integ-telemetry-mc_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-telemetry-mc

integ-pilot-istiodremote-mc_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot-istiodremote-mc

integ-pilot-multicluster_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot-multicluster

integ-basic-arm64_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-basic-arm64

integ-ds_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-ds

integ-telemetry-discovery_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry-discovery

integ-ipv6_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-ipv6

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-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test unit-tests

integ-helm_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-helm

integ-pilot-istiodremote_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot-istiodremote

integ-pilot_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot

integ-cni_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-cni

integ-pilot-istiodremote-mc_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot-istiodremote-mc

integ-pilot-multicluster_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot-multicluster

integ-basic-arm64_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-basic-arm64

integ-ds_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-ds

integ-telemetry-discovery_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry-discovery

integ-ipv6_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-ipv6

integ-telemetry_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry

unit-tests-arm64_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test unit-tests-arm64

gencheck_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test gencheck

integ-telemetry-istiodremote_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry-istiodremote

integ-telemetry-mc_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry-mc

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-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test unit-tests

integ-helm_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-helm

integ-pilot-istiodremote_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot-istiodremote

integ-cni_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-cni

integ-pilot-istiodremote-mc_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot-istiodremote-mc

integ-pilot-multicluster_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot-multicluster

integ-basic-arm64_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-basic-arm64

integ-ds_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-ds

integ-telemetry-discovery_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry-discovery

integ-ipv6_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-ipv6

integ-telemetry_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry

unit-tests-arm64_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test unit-tests-arm64

gencheck_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test gencheck

integ-telemetry-istiodremote_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry-istiodremote

integ-telemetry-mc_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry-mc

integ-pilot_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-pilot

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-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test unit-tests

integ-helm_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-helm

integ-pilot-istiodremote_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot-istiodremote

integ-cni_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-cni

integ-pilot-istiodremote-mc_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot-istiodremote-mc

integ-pilot-multicluster_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot-multicluster

integ-basic-arm64_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-basic-arm64

integ-ds_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-ds

integ-telemetry-discovery_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry-discovery

integ-ipv6_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-ipv6

integ-telemetry_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry

unit-tests-arm64_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test unit-tests-arm64

gencheck_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test gencheck

integ-telemetry-istiodremote_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry-istiodremote

integ-telemetry-mc_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry-mc

integ-pilot_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-pilot

integ-ambient_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-ambient

lint_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test lint

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-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test unit-tests

integ-helm_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-helm

integ-cni_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-cni

integ-pilot-istiodremote-mc_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot-istiodremote-mc

integ-pilot-multicluster_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot-multicluster

integ-basic-arm64_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-basic-arm64

integ-ds_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-ds

integ-telemetry-discovery_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry-discovery

integ-ipv6_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-ipv6

integ-telemetry_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry

unit-tests-arm64_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test unit-tests-arm64

gencheck_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test gencheck

integ-telemetry-istiodremote_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry-istiodremote

integ-telemetry-mc_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry-mc

integ-pilot_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-pilot

integ-ambient_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-ambient

lint_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test lint

integ-pilot-istiodremote_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-pilot-istiodremote

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-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test unit-tests

integ-cni_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-cni

integ-pilot-istiodremote-mc_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot-istiodremote-mc

integ-pilot-multicluster_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot-multicluster

integ-basic-arm64_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-basic-arm64

integ-ds_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-ds

integ-telemetry-discovery_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry-discovery

integ-ipv6_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-ipv6

integ-telemetry_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry

unit-tests-arm64_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test unit-tests-arm64

gencheck_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test gencheck

integ-telemetry-istiodremote_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry-istiodremote

integ-telemetry-mc_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry-mc

integ-pilot_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-pilot

integ-ambient_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-ambient

lint_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test lint

integ-pilot-istiodremote_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-pilot-istiodremote

integ-helm_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-helm

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-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test unit-tests

integ-cni_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-cni

integ-pilot-multicluster_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-pilot-multicluster

integ-basic-arm64_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-basic-arm64

integ-ds_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-ds

integ-telemetry-discovery_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry-discovery

integ-ipv6_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-ipv6

integ-telemetry_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry

unit-tests-arm64_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test unit-tests-arm64

gencheck_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test gencheck

integ-telemetry-istiodremote_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry-istiodremote

integ-telemetry-mc_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry-mc

integ-pilot_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-pilot

integ-ambient_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-ambient

lint_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test lint

integ-pilot-istiodremote_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-pilot-istiodremote

integ-helm_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-helm

integ-pilot-istiodremote-mc_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-pilot-istiodremote-mc

integ-security-istiodremote_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-security-istiodremote

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-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test unit-tests

integ-cni_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test integ-cni

integ-basic-arm64_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-basic-arm64

integ-ds_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-ds

integ-telemetry-discovery_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry-discovery

integ-ipv6_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-ipv6

integ-telemetry_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry

unit-tests-arm64_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test unit-tests-arm64

gencheck_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test gencheck

integ-telemetry-istiodremote_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry-istiodremote

integ-telemetry-mc_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry-mc

integ-pilot_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-pilot

integ-ambient_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-ambient

lint_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test lint

integ-pilot-istiodremote_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-pilot-istiodremote

integ-helm_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-helm

integ-pilot-istiodremote-mc_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-pilot-istiodremote-mc

integ-security-istiodremote_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-security-istiodremote

integ-pilot-multicluster_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-pilot-multicluster

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-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test unit-tests

integ-basic-arm64_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-basic-arm64

integ-ds_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-ds

integ-telemetry-discovery_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry-discovery

integ-ipv6_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-ipv6

integ-telemetry_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry

unit-tests-arm64_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test unit-tests-arm64

gencheck_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test gencheck

integ-telemetry-istiodremote_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry-istiodremote

integ-telemetry-mc_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry-mc

integ-pilot_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-pilot

integ-ambient_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-ambient

lint_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test lint

integ-pilot-istiodremote_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-pilot-istiodremote

integ-helm_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-helm

integ-pilot-istiodremote-mc_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-pilot-istiodremote-mc

integ-security-istiodremote_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-security-istiodremote

integ-pilot-multicluster_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-pilot-multicluster

integ-cni_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-cni

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-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test unit-tests

integ-basic-arm64_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-basic-arm64

integ-ds_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-ds

integ-telemetry-discovery_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry-discovery

integ-ipv6_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-ipv6

integ-telemetry_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry

unit-tests-arm64_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test unit-tests-arm64

gencheck_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test gencheck

integ-telemetry-istiodremote_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry-istiodremote

integ-telemetry-mc_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry-mc

integ-pilot_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-pilot

integ-ambient_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-ambient

lint_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test lint

integ-pilot-istiodremote_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-pilot-istiodremote

integ-helm_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-helm

integ-pilot-istiodremote-mc_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-pilot-istiodremote-mc

integ-security-istiodremote_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-security-istiodremote

integ-pilot-multicluster_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-pilot-multicluster

integ-cni_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-cni

integ-security-multicluster_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-security-multicluster

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-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests_istio
367e4af26a65bf2c1b3c8ce6ea2e7a72b81eb4c9
link
true
/test unit-tests

integ-basic-arm64_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-basic-arm64

integ-ds_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-ds

integ-telemetry-discovery_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry-discovery

integ-ipv6_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-ipv6

integ-telemetry_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry

unit-tests-arm64_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test unit-tests-arm64

gencheck_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test gencheck

integ-telemetry-istiodremote_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry-istiodremote

integ-telemetry-mc_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry-mc

integ-pilot_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-pilot

integ-ambient_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-ambient

lint_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test lint

integ-pilot-istiodremote_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-pilot-istiodremote

integ-helm_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-helm

integ-pilot-istiodremote-mc_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-pilot-istiodremote-mc

integ-security-istiodremote_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-security-istiodremote

integ-pilot-multicluster_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-pilot-multicluster

integ-cni_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-cni

integ-security-multicluster_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-security-multicluster

integ-distroless_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-distroless

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-sigs/prow repository. I understand the commands that are listed here.

@bleggett @ilrudie Do we have any thoughts on having the helm.sh tags even though these charts could be used outside of helm? I feel like deleting it to avoid confusion, but I'm not super familiar with the installation mode landscape.

I'd say leave it. We don't really need to be ashamed or hide that istioctl is based on helm templating IMO. We could also just gate it with a check if we want and only apply them when release.service is helm

If you use a Helm chart outside of Helm it's still a Helm chart and your usage of it must be compliant with Helm, so yep.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-telemetry-mc_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-telemetry-mc

integ-pilot_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-pilot

integ-ambient_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-ambient

integ-pilot-istiodremote_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-pilot-istiodremote

integ-pilot-istiodremote-mc_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-pilot-istiodremote-mc

integ-security-istiodremote_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-security-istiodremote

integ-pilot-multicluster_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-pilot-multicluster

integ-cni_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-cni

integ-security-multicluster_istio
c24d1a137a2907e1415b16ed22a9b8c84e4cf371
link
true
/test integ-security-multicluster

integ-telemetry-istiodremote_istio
1f6005aa11d1cbec438c38cd764592bf69d8b29e
link
true
/test integ-telemetry-istiodremote

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-sigs/prow repository. I understand the commands that are listed here.

/retest

@bleggett @ilrudie Any tips for the failing test?

@bleggett @ilrudie Any tips for the failing test? Currently trying to reproduce locally, but maybe there is a faster way.

Locally is probably best. Reach out if you need help running the tests locally.
I see
  stats_test.go:236: Series 0 (source: echo-3-85351/b-v1-7bdbd6c949-vcd8f)
    stats_test.go:236:   for label "destination_canonical_revision", wanted "latest" but got "1.0.0"
    stats_test.go:236: Series 1 (source: echo-3-85351/a-v1-6cc95f66b9-hkmsr)
    stats_test.go:236:   for label "destination_service_namespace", wanted "istio-system" but got "unknown"
    stats_test.go:236:   for label "destination_workload_namespace", wanted "istio-system" but got "unknown"
    stats_test.go:236:   for label "destination_service_name", wanted "istio-egressgateway" but got "PassthroughCluster"
    stats_test.go:236:   for label "destination_app", wanted "istio-egressgateway" but got "unknown"
    stats_test.go:236:   for label "destination_canonical_service", wanted "istio-egressgateway" but got "unknown"
    stats_test.go:236: Series 2 (source: echo-3-85351/a-v1-6cc95f66b9-hkmsr)
    stats_test.go:236:   for label "destination_canonical_service", wanted "istio-egressgateway" but got "b"
    stats_test.go:236:   for label "destination_app", wanted "istio-egressgateway" but got "b"
    stats_test.go:236:   for label "destination_workload_namespace", wanted "istio-system" but got "echo-3-85351"
    stats_test.go:236:   for label "destination_service_name", wanted "istio-egressgateway" but got "b"
    stats_test.go:236:   for label "destination_canonical_revision", wanted "latest" but got "v1"
    stats_test.go:236:   for label "destination_service_namespace", wanted "istio-system" but got "echo-3-85351"
    stats_test.go:236: Series 3 (source: istio-system/istio-egressgateway-888c5bfc4-xt8xt)
    stats_test.go:236:   for label "destination_app", wanted "istio-egressgateway" but got "b"
    stats_test.go:236:   for label "destination_workload_namespace", wanted "istio-system" but got "echo-3-85351"
    stats_test.go:236:   for label "destination_canonical_service", wanted "istio-egressgateway" but got "b"
    stats_test.go:236:   for label "destination_service_namespace", wanted "istio-system" but got "echo-3-85351"
    stats_test.go:236:   for label "reporter", wanted "source" but got "destination"
    stats_test.go:236:   for label "destination_service_name", wanted "istio-egressgateway" but got "b"
    stats_test.go:236:   for label "destination_canonical_revision", wanted "latest" but got "v1"
    stats_test.go:236: Series 4 (source: echo-3-85351/a-v1-6cc95f66b9-hkmsr)
    stats_test.go:236:   for label "destination_workload_namespace", wanted "istio-system" but got "external-2-94845"
    stats_test.go:236:   for label "source_workload_namespace", wanted "echo-3-85351" but got "istio-system"
    stats_test.go:236:   for label "destination_app", wanted "istio-egressgateway" but got "unknown"
    stats_test.go:236:   for label "destination_canonical_service", wanted "istio-egressgateway" but got "external"
    stats_test.go:236:   for label "destination_service_namespace", wanted "istio-system" but got "external-2-94845"
    stats_test.go:236:   for label "source_app", wanted "a" but got "istio-egressgateway"
    stats_test.go:236:   for label "destination_service_name", wanted "istio-egressgateway" but got "external"
    stats_test.go:236:   for label "destination_canonical_revision", wanted "latest" but got "v1"
    stats_test.go:236:   for label "source_workload", wanted "a-v1" but got "istio-egressgateway"
    stats_test.go:236:   missing labels: [source_version]

which are for metrics labels not kube labels - but I wonder if we have bad logic/test code that expects certain K8S labels to map to specific metrics labels.
If we do, that's a bit of a smell but it shouldn't be hard to fix either way if that's what's happening,

which are for metrics labels not kube labels - but I wonder if we have bad logic/test code that expects certain K8S labels to map to specific metrics labels.

We do, app.kubernetes.io/version  (from https://github.com/istio/istio/blob/6fbfc2b7af34b60cf1d1b480a32a0a846f7367d5/manifests/charts/istio-control/istio-discovery/files/injection-template.yaml#L37)

The issue seems to be from the  app.kubernetes.io/version: {{ .Chart.AppVersion | quote }} label in the egress gateway injection-deployment.yaml. When I leave it out (but include all the other labels), the test passes.

So @howardjohn was right.
The issue was that the telemetry tests were expecting the service.istio.io/canonical-revision tag on the egress deployment to be set to latest, but it ended up being 1.0.0 because app.kubernetes.io/version was being set to .Chart.AppVersion which is 1.0.0. Usually, .Chart.AppVersion doesn't matter because

This version is never actually shipped. istio/release-builder will replace it at build-time with the appropriate version.

However, the "version" does matter because we aren't running the Helm charts through istio/release-builder.
I changed the test so it it checks for 1.0.0 instead of latest so that the pipelines (hopefully) pass.
That being said, I think a better solution is to change the Chart.yaml files to have a version and appVersion of latest.
I think its more correct and shouldn't affect releases.
I don't feel strongly about this however, and just changing the test might be the way to go if changing the version and appVersion fields on all Chart.yamls break other tests.

@Stevenjin8: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-telemetry-discovery_istio
b46e39b3949c546e4d28904284282323767fadf6
link
true
/test integ-telemetry-discovery

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-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-telemetry-discovery_istio
b46e39b3949c546e4d28904284282323767fadf6
link
true
/test integ-telemetry-discovery

integ-telemetry_istio
b46e39b3949c546e4d28904284282323767fadf6
link
true
/test integ-telemetry

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-sigs/prow repository. I understand the commands that are listed here.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-telemetry-discovery_istio
b46e39b3949c546e4d28904284282323767fadf6
link
true
/test integ-telemetry-discovery

integ-telemetry_istio
b46e39b3949c546e4d28904284282323767fadf6
link
true
/test integ-telemetry

integ-telemetry-mc_istio
b46e39b3949c546e4d28904284282323767fadf6
link
true
/test integ-telemetry-mc

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-sigs/prow repository. I understand the commands that are listed here.

I don't think the issue is testing, its whether we want to start reporting the chart version in metrics for our gateways or continue doing latest. That will be a behavioral change for users

I think I'm going to try changing the Chart.yaml values.

latest is not a semver AFAIK.
0.0.0 or 1.0.0 are pretty standard for "unset" versions in test/prerelease builds.
What are the expected semantics of  service.istio.io/canonical-revision, and how do they differ from app.kubernetes.io/version?
We don't have to alias those two if we don't want to, the former is our own invention anyway.

@bleggett You're right, I ran into a bunch of validation issues for latest. We have three different ways of setting service.istio.io/canonical-revision

{{ index .ObjectMeta.Labels service.istio.io/canonical-revision| default (index .ObjectMeta.Labelsapp.kubernetes.io/version) | default (index .ObjectMeta.Labels version) | default "latest"  | quote }}
"latest"
{{ index $gateway.labels "app.kubernetes.io/version" | default (index $gateway.labels "version") | default .Values.revision | default "latest" | quote }}

@bleggett You're right, I ran into a bunch of validation issues for latest. We have three different ways of setting service.istio.io/canonical-revision
* `` {{ index .ObjectMeta.Labels service.istio.io `canonical-revision` | default "latest"  | quote }} ``

Would be my pref - if we want canonical-revision (our label) to do something special, we should set it and use it accordingly and disentangle it from the standard ones.

Can we take a step back here... we went from trying to make consistent helm chart labels, to fundamentally changing how Istio telemetry works for users applications.
Istio telemetry reports two labels - version and canonical revision. These are basically the same thing, but they are a part of the core v1 telemetry schema, which is probably the most important API in Istio. We absolutely should not change that (without serious consideration).
How those get populated is based on labels on the pod. This is derived from the set of three labels for maximum compatibility and historical compatibility (back in the day version was all the rage, then people decided they liked long names like app.kubernetes.io/version).
None of this should change without extremely compelling reasons.
What we can change is Chart.yaml and the labels we set on the gateway on install. Chart.yaml changes don't make sense IMO -- we are just trying to work around our test suite legitimately finding a breaking change in this PR, which is the wrong problem to solve.
So then we have label on the gateway. We have two choices:

We can put app.kubernetes.io/version on it, and achieve consistency, and accept this will not be a tiny invisible change to users and instead propagate into their metrics.
We don't put the label, and keep the status quo.

I am not so against putting the label, tbh, but I worry a bit that we are doing it for the wrong reasons, which might suggest we shouldn't be doing it at all. If our goal is to just have consistent labels, that is a niche improvement ultimately -- making a major behavioral change as a side effect is not great. If we legitimately want to report Istio version in that part of the metric, I can see an argument for that.. I just haven't heard anyone suggest that is actually what they want (either on this PR or in general discussions).

Can we take a step back here... we went from trying to make consistent helm chart labels, to fundamentally changing how Istio telemetry works for users applications.

Yep, which is a strong signal we have a bug (or at least a fragile assumption) here.

Istio telemetry reports two labels - version and canonical revision. These are basically the same thing, but they are a part of the core v1 telemetry schema, which is probably the most important API in Istio. We absolutely should not change that (without serious consideration).

Yep, it's unfortunate our usage of one of those standard labels is nonstandard and fragile.
We have two labels - one of them is standardized, and using it in a standard fashion shouldn't break anything.
The other is our label, and we can do what we want with that. The problem is we're creating an implicit relationship between them that doesn't actually hold.

How those get populated is based on labels on the pod. This is derived from the set of three labels for maximum compatibility and historical compatibility (back in the day version was all the rage, then people decided they liked long names like app.kubernetes.io/version).
None of this should change without extremely compelling reasons.
What we can change is Chart.yaml and the labels we set on the gateway on install. Chart.yaml changes don't make sense IMO -- we are just trying to work around our test suite legitimately finding a breaking change in this PR, which is the wrong problem to solve.
So then we have label on the gateway. We have two choices:
* We can put `app.kubernetes.io/version` on it, and achieve consistency, and accept this will not be a tiny invisible change to users and instead propagate into their metrics.

* We don't put the label, and keep the status quo.

Or we can set both app.kubernetes.io/version and service.istio.io/canonical-revision on the gateway, and munge the latter uniquely to have whatever magic Istio-specific values our code expects it to have, right?
This should be as simple as if app.kubernetes.io/version==1.0.0 then set service.istio.io/canonical-revision=latest in the gateway chart, correct? Which is kludgy but it will do for now.

If our goal is to just have consistent labels, that is a niche improvement ultimately -- making a major behavioral change as a side effect is not great.

I agree - the behavioral change is a symptom of a larger underlying issue tho - we're using a standard label in a nonstandard way, and what should be a simple change breaks telemetry, because we do this. This doesn't seem desirable in the long term.

If we legitimately want to report Istio version in that part of the metric, I can see an argument for that.. I just haven't heard anyone suggest that is actually what they want (either on this PR or in general discussions).

The goals are stated in https://github.com/istio/istio/issues/52034

Introduce shared templating for labels that should be common, to avoid bugs and UX issues around inconsistent usage of labels between charts (which we have had bugs around)
Use that to eventually allow for user-applied labels consistently across charts (which we have also had bugs around)
Flush out weird dependencies on non-standard uses of standard labels so we can fix them (what we have here).

I feel like this is pretty simple - we are doing something nonstandard with a standard label. We should not do that, and already have our own label for this that can be as nonstandard as we want.
It's unfortunate we hit that here, but part of forcing consistency is it tends to flush out these weird gotchas which eventually end up causing problems for us, because we impose Istio opinions on rest-of-the-world opinions.

Or we can set both app.kubernetes.io/version and service.istio.io/canonical-revision on the gateway, and munge the latter uniquely to have whatever magic Istio-specific values our code expects it to have, right?

I was thinking we set both version and canonical_revision with the same precedence. But looks like version ONLY comes from version directly interestingly.
So yeah I think we could do that if we want.

This should be as simple as if app.kubernetes.io/version==1.0.0 then set service.istio.io/canonical-revision=latest in the gateway chart, correct? Which is kludgy but it will do for now.

There should not be anything special about 1.0.0 (other than our test failing)? The issue is not the test changing from latest to 1.0.0 but from real users metrics changing from latest to 1.24.2 or whatever.

I feel like this is pretty simple - we are doing something nonstandard with a standard label.

What is nonstandard? We are reading the standard "version" label, and reporting it in a "version" attribute on a metric?

Or we can set both app.kubernetes.io/version and service.istio.io/canonical-revision on the gateway, and munge the latter uniquely to have whatever magic Istio-specific values our code expects it to have, right?

I was thinking we set both version and canonical_revision with the same precedence. But looks like version ONLY comes from version directly interestingly.
So yeah I think we could do that if we want.

OK - if @Stevenjin8 tells me this can't be solved I'm open to something else, but something like that seems reasonable/a good flush-out.

This should be as simple as if app.kubernetes.io/version==1.0.0 then set service.istio.io/canonical-revision=latest in the gateway chart, correct? Which is kludgy but it will do for now.

There should not be anything special about 1.0.0 (other than our test failing)? The issue is not the test changing from latest to 1.0.0 but from real users metrics changing from latest to 1.24.2 or whatever.

Hmm, I am not sure how valuable user metrics with a version tag of latest actually are, but yeah I agree even if the behavior isn't great, we should maintain the not-great behavior here in a back compat way (which I think we can do)

I feel like this is pretty simple - we are doing something nonstandard with a standard label.

What is nonstandard? We are reading the standard "version" label, and reporting it in a "version" attribute on a metric?

Yep. I stand corrected/to be fair to your argument, the kube definition doesn't say app.kubernetes.io/version must be a semver.
It's more that we expect it to not be a semver in some cases and break unless it is, which is puzzling, and maybe something to consider improving. Telemetry for version latest is not particularly useful for the same reason a docker ref of latest isn't particularly recommended.

It's more that we expect it to not be a semver in some cases and break assumptions unless this implicit rule is upheld, which is puzzling, unnecessarily confusing, and maybe something to consider improving. Telemetry for version latest is not particularly useful for the same reason a docker ref of latest isn't particularly recommended - if I look at a database of those collected metrics 6 months from now, what does latest mean?

Ah I think this is the confusion. There is no semver constraint anywhere, you can put apple as the version if you want.
The only semver thing is the Chart.yaml stuff which (in my opinion) is irrelevant to the discussions here.
The only issue with putting the version here is the metric name changes from latest to 1.22.4 when a user upgrades. That may or may not be a behavioral change we want to introduce.

The only issue with putting the version here is the metric name changes from latest to 1.22.4 when a user upgrades. That may or may not be a behavioral change we want to introduce.

That's fair enough, we can circulate that in the WG.
Emitting telemetry to users with version = latest seems like a UX problem/behavioral bug on our part as it's not a useful signal, so I think emitting the actual version versus a meaningless placeholder in metrics would be an improvement.

Emitting telemetry to users with version = latest seems like a UX problem/behavioral bug on our part as it's not a useful signal, so I think emitting the actual version versus a meaningless placeholder in metrics would be an improvement.

Yeah just to be clear, I like 90% agree with this. But want to make sure if we change this, its because we think its actually the right behavior (and go write some release notes, etc) not an accidental behavioral change as part of a unrelated improvement (which I like the improvement btw!)

Emitting telemetry to users with version = latest seems like a UX problem/behavioral bug on our part as it's not a useful signal, so I think emitting the actual version versus a meaningless placeholder in metrics would be an improvement.

Yeah just to be clear, I like 90% agree with this. But want to make sure if we change this, its because we think its actually the right behavior (and go write some release notes, etc) not an accidental behavioral change as part of a unrelated improvement (which I like the improvement btw!)

I threw it in the WG doc - @Stevenjin8 if you can or want to attend you can talk about it, or we can if you cannot, either way is fine.

@howardjohn @bleggett So just to make sure I understand, the nonbreaking way to do this is change the way we set service.istio.io/version to not depend on app.kubernetes.io/version. That is, we go from
service.istio.io/version: {{ index $gateway.labels "app.kubernetes.io/version" | default (index $gateway.labels "version") | default .Values.revision | default "latest" | quote }}

to something like
service.istio.io/version: {{ default (index $gateway.labels "version") | default .Values.revision | default "latest" | quote }}

This way, for the gateways, we can set app.kubernetes.io/version in a standard way (i.e. using the template) without changing service.istio.io/version from latest to 1.24.0 (or whatever the current version is).
That being said, changing service.istio.io/version to reflect the current istio version seems like a better idea and the only thing holding us back are compatibility concerns. Hence why we should discuss it in the WG meeting.

That being said, changing service.istio.io/version to reflect the current istio version seems like a better idea and the only thing holding us back are compatibility concerns. Hence why we should discuss it in the WG meeting.

Yes.
It's demonstrably a bug if we are emitting "latest" as an Istio version for any builds or deployments outside of integration tests or pre-releases, instead of the actual version, but fixing the bug is a behavioral change.

@Stevenjin8: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-telemetry-discovery_istio
b46e39b3949c546e4d28904284282323767fadf6
link
true
/test integ-telemetry-discovery

integ-telemetry_istio
b46e39b3949c546e4d28904284282323767fadf6
link
true
/test integ-telemetry

integ-telemetry-mc_istio
b46e39b3949c546e4d28904284282323767fadf6
link
true
/test integ-telemetry-mc

gencheck_istio
abcec29e1c005b15bbae79192d1932a8e7213fc4
link
true
/test gencheck

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-sigs/prow repository. I understand the commands that are listed here.

Oh one thing I forgot... if you set --revision, the revision becomes the service.istio.io/canonical-revision. So it may be weird that you have something like  1.24.0 without revision, and my-revision-name with revision. (Its also weird that its latest and not default...)

Oh one thing I forgot... if you set --revision, the revision becomes the service.istio.io/canonical-revision. So it may be weird that you have something like 1.24.0 without revision, and my-revision-name with revision. (Its also weird that its latest and not default...)

Why would that be weird? Is the control plane revision different than the canonical revision?

Why would that be weird? Is the control plane revision different than the canonical revision?

So in the Istio metric itself, showing up in prometheus.
Today: if I use revisions, it is <revision>, else latest.  This is a little funky since we generally call 'no revision' default, not latest, but at least its somewhat consistent.
This PR: if I use revisions, it is <revision>, else it is <version>. This is entirely inconsistent

Why would that be weird? Is the control plane revision different than the canonical revision?

So in the Istio metric itself, showing up in prometheus.
Today: if I use revisions, it is <revision>, else latest. This is a little funky since we generally call 'no revision' default, not latest, but at least its somewhat consistent. This PR: if I use revisions, it is <revision>, else it is <version>. This is entirely inconsistent

So we have a homegrown label with terribly confusing and contradictory semantics that only barely works today :D
Under what conditions should service.istio.io/canonical-revision contain the actual release version at all, in the current code?
Is it

Never?
When revision is unset?
When revision is unset and $some-other-condition?

None of these are impossible to express in our custom label, and none of them prevent us from using standard versioning labels.
in any case it seems pretty clear that service.istio.io/canonical-revision  should be entirely divorced from standard versioning labels, as it has little to do with them and follows some rather opaque internal semantics.
Either service.istio.io/canonical-revision 's current behavior can be expressed logically, and we can make it work in a backwards compatible way, or it cannot be expressed logically, and it doesn't currently work in the slightest. It's one or the other.
Going back to the previous comment, if the problem is that we have a custom, badly-overloaded label we need to express back compat for, that's probably still just:
if app.kubernetes.io/version==1.0.0 then set service.istio.io/canonical-revision=latest unless values.revision

@bleggett I wonder if there is confusion based on the naming of things? There is like 5 phrases and each one has 3 definitions, so it gets messy.
This may just be incomprehensible or it may help... what if we look at it with alternative names?

Istio metrics has a source_foobar and dest_foobar label added to them to help categorize traffic. This is derived from the istio/foobar pod label, but if its not set it falls back to foo-bar or k8s/foobar for maximum compatibility.
Istio's helm charts currently set this do be latest if there is no revision set, or <revision> if revision is set.
This PR changes it to be <chart version> instead.

Now, using this framing to answer your questions.

Under what conditions should ~service.istio.io/canonical-revision~ source_foobar contain the actual release version at all, in the current code?

For users applications: whenever they want, they are able to chose the semantics of their own labeling scheme
For Istio gateway, without considering history: :shrug:
For istio gateway, considering history: probably never since it has not historically done so, unless we want to change that

in any case it seems pretty clear that ~service.istio.io/canonical-revision~ source_foobar should be entirely divorced from the ~standard versioning~ foo-bar/k8s/foobar labels

(TBH the analogy is not helping here). I don't agree.
Biggest issue here is backwards compatibility. Its one thing to change the metric label for the gateway. Its another thing to change it for every users application - that has a huge implication.
Even still, I don't see why its bad? It seems like a good idea to collect information from various sources to support more workloads.

if app.kubernetes.io/version==1.0.0 then set service.istio.io/canonical-revision=latest unless values.revision

I don't think this is logic we ever want to introduce, that is essentially if deploying from github { ... }; that is a huge smell.
This isn't actually maintaining compatibility -- all real users will get the behavioral change, this only makes it so our integration tests don't notice we broke compatibility.

the tl;dr is that if these weird semantics mattered significantly, we'd have tests around them. The tests we do have around them are passing here AFAICT (and are not being "made to pass" but are in fact passing as-is).

They do, that is why they were failing in the test until a workaround was added specifically to appease the test. There are also many other tests that exercise this as well. Its really not fair to say "We broke a test in a pretty specific scenario, then worked around it and now everything passes, so the behavior doesn't matter"...

For users applications: whenever they want, they are able to chose the semantics of their own labeling scheme
Fair enough, for the purposes of this PR we don't really care if people set this explicitly.

For Istio gateway, without considering history: 🤷

For istio gateway, considering history: probably never since it has not historically done so, unless we want to change that

in any case it seems pretty clear that ~service.istio.io/canonical-revision~ source_foobar should be entirely divorced from the ~standard versioning~ foo-bar/k8s/foobar labels

(TBH the analogy is not helping here). I don't agree.
Biggest issue here is backwards compatibility. Its one thing to change the metric label for the gateway. Its another thing to change it for every users application - that has a huge implication.

So that means we should just do IF rev IS SOMETHING THEN service.istio.io/canonical-revision=rev ELSE service.istio.io/canonical-revision=latest?
I've no objection to that - if that's what it should be, then let's set it to that. If that's true then falling back to "app version" for canonical-revision seems to be the wrong choice in all cases, since it's supposed to be the revision and not the version, which are, in Istio, two entirely unrelated things (unless by local convention, which our charts shouldn't assume)?
There are three possibilities here:

the label is a revision, in which case it is not a version at all and all existing places where we set it to a raw version are a bug.
the label is a version, in which case it is not a revision at all and all existing places where we set it to a revision are a bug.
the label is sometimes a version and sometimes a revision, in which case the label has bad semantics, it's currently broken, it should be fundamentally reworked, and fixing it is out of scope of this PR, as long as we can throw together a temp workaround for this label of ours with bad semantics that satisfies $BACKWARDS_COMPAT_CONSTRAINTS.

It's not clear to me if you are arguing that $BACKWARDS_COMPAT_CONSTRAINTS cannot be met in this PR (which I think is simply logically not true, especially without test cases to demonstrate as such), or you are arguing that they can be met, but we aren't meeting them, and the lack of tests that actually fence those constraints are making it hard for me to understand what you're expressing.

They do, that is why they were failing in the test until a workaround was added specifically to appease the test. There are also many other tests that exercise this as well. Its really not fair to say "We broke a test in a pretty specific scenario, then worked around it and now everything passes, so the behavior doesn't matter"...

What's the workaround you object to, exactly? In what way is it not meeting the test requirements?
What would a test that would fence the behavior you're talking about here look like?

Today: if I use revisions, it is , else latest. This is a little funky since we generally call 'no revision' default, not latest, but at least its somewhat consistent.
This PR: if I use revisions, it is , else it is . This is entirely inconsistent

I think this is the incompatibility that @howardjohn is referring to and I don't think this is true.
I'm not going to use source_foo notation because I don't super understand it.
But as it stands right now, not setting --revision will result in a service.istio.io/revision=latest while setting it to myrevision will set service.istio.io/revision=myrevision (at least for the gateways in my testing).
I think this is why @bleggett approved this PR and said we can discuss changes to service.istio.io/revision's default value in another PR, because that would be a breaking change.
I will also note that I did not add any if-else logic for service.istio.io/revision nor are there any changes to the tests (there used to be but I reverted them).

ty @Stevenjin8 !


Issue with Bracket Matching Highlighting

Windows 10 Version 1703 Build 15063.413
VSCode v.1.13.1
Subtle Match Brackets v.2.0.0
Material Theme v.0.0.17
Other Installed Extensions:
Beautify v.1.1.1
Wrong bracket matching highlighting if on top we have commented code snippet using block comments.
I record a video to show what happens:
https://youtu.be/BPjKUSWNigw
My VSCode config:
// Place your settings in this file to overwrite the default settings
{
    "editor.fontSize": 17,
    "editor.fontFamily": "Consolas",
    "editor.tabSize": 4,
    "git.enabled": true,
    "explorer.openEditors.visible": 9,
    "explorer.enableDragAndDrop": true,
    "files.encoding": "utf8",
    "files.eol": "\r\n",
    "files.insertFinalNewline": true,
    "files.autoSave": "off",
    "window.openFilesInNewWindow": "default",
    "editor.renderWhitespace": "none",
    "window.zoomLevel": 0,
    "workbench.welcome.enabled": true,
    "editor.lineHeight": 24,
    "editor.fontLigatures": true,
    "terminal.integrated.shell.windows": "C:\\Windows\\sysnative\\bash.exe",
    "workbench.colorTheme": "Material Theme",
    "workbench.iconTheme": "material-theme-icons",
    "editor.minimap.enabled": true,
    "editor.dragAndDrop": true,
    "editor.minimap.renderCharacters": false,
    "editor.cursorBlinking": "blink",
    "workbench.activityBar.visible": true,
    "workbench.statusBar.visible": true,
    "editor.mouseWheelZoom": false,
    "editor.renderIndentGuides": true,
    "editor.renderLineHighlight": "all",
    "editor.matchBrackets": false,
    "diffEditor.renderSideBySide": true,
    "editor.multiCursorModifier": "ctrlCmd",
    "extensions.autoUpdate": false,
    "subtleBrackets.disableNative": true,
    "subtleBrackets.parse": true,
    "subtleBrackets.styles": {
        "global": {
            "borderWidth": "1px",
            "borderStyle": "none none solid none",
            "borderColor": "#FFCC00"
        }
    }
}

Code from video:
router.get('/product/:id', function(req, res, next) {
	Product
		.findOne({
			_id: req.params.id
		})
		.populate('review', {
			data: {
				$slice: [0, 5]
			}
		})
		.exec(function(err, foundProduct) {
			res.render('main/product', {
				product: foundProduct
			})
		})
})

router.post('/review', function(req, res, next) {
	Review.findOne({
		product: req.body.this_product_id
	}, function(err, foundReview) {
		if (err) throw err

		foundReview.data.push({
			author: req.user.profile.name,
			author_email: req.user.email,
			content: req.body.review,
			date: new Date().toISOString(),
			recommended: ((req.body.recommended) ? true : false)
		})

		foundReview.save(function(err) {
			if (err) throw err
			callback(null, foundReview)
		})
	})
})

This issue not present with disabled Subtle Match Brackets extension on default VSCode"box" matching highlighting.

@rafamel also I noticed that with plain text this not present. Only when syntax highlighting selected.

This is due to the method by which subtleBrackets uses Prism to implement proper parsing. I've pushed a new version, it should now be solved. Thanks for reporting it and sorry for the delay on this! Tell me how it goes

@rafamel thanks a lot! Now that's works well. Thanks to your work now it's possible to use the familiar brackets matching highlighting style as in Sublime Text 3 in VSCode.

@rafamel thanks a lot! Now that's works well. Thanks to your work now it's possible to use the familiar brackets matching highlighting style as in Sublime Text 3 in VSCode.

@rafamel thanks a lot! Now that's works well. Thanks to your work now it's possible to use the familiar brackets matching highlighting style as in Sublime Text 3 in VSCode.

@rafamel thanks a lot! Now that's works well. Thanks to your work now it's possible to use the familiar brackets matching highlighting style as in Sublime Text 3 in VSCode.

@rafamel thanks a lot! Now that's works well. Thanks to your work now it's possible to use the familiar brackets matching highlighting style as in Sublime Text 3 in VSCode.

@rafamel thanks a lot! Now that's works well. Thanks to your work now it's possible to use the familiar brackets matching highlighting style as in Sublime Text 3 in VSCode.

@rafamel thanks a lot! Now that's works well. Thanks to your work now it's possible to use the familiar brackets matching highlighting style as in Sublime Text 3 in VSCode.

@rafamel thanks a lot! Now that's works well. Thanks to your work now it's possible to use the familiar brackets matching highlighting style as in Sublime Text 3 in VSCode.


terraria-server: <IP_ADDRESS> -> <IP_ADDRESS>

Motivation for this change
Update to the latest version.
Things done

[X] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[X] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[X] Ensured that relevant documentation is up to date
[X] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 89878 1

1 package built:
- terraria-server