Antoine Cotten

Ping @odacremolbap. I didn't assign you but feel free to do so if you're interested in tackling this.

Now that the Zendesk source is multi-tenant, this implementation should be as easy as copying everything from triggermesh/knative-sources#116 and swapping the handler implementation.

Looks like it _does_ support label selectors: https://github.com/knative/pkg/blob/2267a4cbebb8b4004b00e5f01fa9b9fb6c5d69e7/tracker/enqueue.go#L94-L115

Extra note: leases may expire inside a `Tracker`, so before migrating we should really ensure that re-syncs will periodically occur for all object instances that watch a multi-tenant adapter. https://pkg.go.dev/knative.dev/pkg/tracker#New...

Agree that the category is probably not necessary. Regarding the unique error type, the `data` part is free form so the consumer must know how to consume it based on...

**Explanation** If the call stack looks like ``` Describe(...) -> func(...) -> BeforeEach(...) -> func(...) -> Helper(...) -> FailfWithOffset(2, ...) ``` We call `ginkgo.Fail()` with an offset of `3` (selected...

I've been thinking about a few more component-specific metrics we could add to the synchronizer. Not sure how badly the code needs to change to implement them but here's what's...

The restriction is indeed specific to Dependabot. It is explained in the following paragraph of the GitHub documentation: > For workflows initiated by Dependabot (`github.actor == "dependabot[bot]"`) using the `pull_request`,...

To recap, it seems like our options are 1. Duplicate secrets as "Dependabot secrets" inside the repo's settings _Doesn't sound very maintainable to me_ 1. Merge PRs from `dependabot` ourselves...

Cross-referencing this long thread in Dependabot's repo: https://github.com/dependabot/dependabot-core/issues/3253