-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reuse context in reconciler #87
Conversation
0d0c15d
to
3be215f
Compare
3be215f
to
dd2da71
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, but do we know where is the ctx
for the Reconcile
function coming from and who sets it?
the logic being, it might be a context that has nothing to do with the actual context we want propagated (in anticipation of #63)
OK So THAT is the answer to my question, the context is initialised there :-) @maruina could prob confirm this. |
I think we should change Regarding the test, I'm not sure about that so I think you can keep the current |
But if they don't generate the context, what will? |
You are correct. I was already thinking in a kubebuilder 3.0 scenario. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Fixes #67.
Two questions:
requestsForApplicationChange
norrequestsForSecretChange
as they are called inhandler.EnqueueRequestsFromMapFunc(r.requestsForApplicationChange)
andhandler.EnqueueRequestsFromMapFunc(r.requestsForSecretChange)
respectively. Should we?ctx
in tests - is there any better approach?