Nic Cope

@vladimirvivien Not that I know of. I believe it's pretty normal to call it repeatedly (e.g. if you have several layers of test helper functions).

@turkenh and I chatted about this a bit the other day. I agree updating resource.Managed to have GetStatus and SetStatus methods would be the most idiomatic way to do it....

> unfortunate we have to do this, but I couldn't find a better way I think `github.com/pkg/errors` used to automatically decorate errors with this context, but it's now deprecated. 🤔...

I tried to find a less hacky feeling way to address this and ended up with https://github.com/kubernetes-sigs/e2e-framework/pull/421. It ends up looking like this: ``` +e2e | I0603 22:29:59.923378 255 environment.go:76]...

> a possible regex to validate packages I definitely don't love how complex that regex is, heh. Ideally we'd use the same logic as `name.StrictValidation` - so e.g. a webhook...

Part of the divergence is due to the complexity of the average provider vs the average function. Few enough folks write providers that we haven't been too worried about making...

@jastang functions don't use the build submodule, mostly they're just using multi-stage Dockerfiles. They use `go.mod` style development versions - i.e. `v0.0.0--`.

@tampakrap Looks like this needs a rebase after I merged your other PR.

https://github.com/crossplane/crossplane/blob/b2ba53f8c/test/e2e/apiextensions_xrds_test.go#L30 There's only one right now, but we have this integration test that tests CEL validation. Can you help me understand why you think we should introduce a new testing...

If we're throwing out theme requests, I'd appreciate GitHub light/dark themes. My system toggles from light to dark at sunset, and I try to keep everything code-y using the appropriate...