-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Implement CloudEvents for Runs #4663
Conversation
59d7d52
to
ff8ad27
Compare
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
ff8ad27
to
c864705
Compare
The following is the coverage report on the affected files.
|
c864705
to
c7fb98e
Compare
The following is the coverage report on the affected files.
|
c7fb98e
to
4e94abf
Compare
The following is the coverage report on the affected files.
|
4e94abf
to
749bdba
Compare
The following is the coverage report on the affected files.
|
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.
I think this would be easier to review if split up into one PR that adds the run controller and one that adds the cloud events (sorry to create more work!)
// cacheKey is a way to associate the Cache from inside the context.Context | ||
type cacheKey struct{} | ||
|
||
func withCacheClient(ctx context.Context, cfg *rest.Config) context.Context { |
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.
there's some duplication here with thewithFakeCacheClient
func below that could probably be pulled into a helper that accepts a buffer size.
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.
done
// d, where d represents the state of the system (existing resources) needed for the test. | ||
func getRunController(t *testing.T, d test.Data) (test.Assets, func()) { | ||
t.Helper() | ||
names.TestingSeed() |
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.
this line can probably be removed from the individual test cases
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.
good catch, done
pkg/reconciler/testing/logger.go
Outdated
@@ -28,6 +30,8 @@ func SetupFakeContext(t *testing.T) (context.Context, []controller.Informer) { | |||
SendSuccessfully: true, | |||
} | |||
ctx = cloudevent.WithClient(ctx, &cloudEventClientBehaviour) | |||
cacheClient, _ := lru.New(128) |
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.
nit: could you please add an inline comment: lru.New(/*bufSize=*/ 128)
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.
Oh, in fact this is not needed anymore, it's handled by injection and I forgot to remove it here
Hi @lbernick - I'm not sure how you would like to split this further 🙏 The only new part in this PR is 749bdba |
749bdba
to
a7a87a7
Compare
The following is the coverage report on the affected files.
|
/test pull-tekton-pipeline-integration-tests |
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.
One small comment, otherwise LGTM 🐯
logger := logging.FromContext(ctx) | ||
|
||
cacheClient, err := lru.New(size) | ||
logger.Infof("CACHE CLIENT %+v", cacheClient) |
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.
Is it required in the logs as info or was it a "debug" ? 😛
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.
Well, since this happens once per controller start-up, I thought it would be useful to have it at info to know that the cache was initialised. If it should up a second time it means something is very wrong!
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: vdemeester The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
I was thinking moving the contents of controller.go and most of run.go into a separate PR (to merge before adding the emitCloudEvents functionality) however I'd be OK with lgtm-ing as is once you rebase this. |
a7a87a7
to
0af7079
Compare
The following is the coverage report on the affected files.
|
Oh, I see. The reason I put this together in one PR is that the only thing the controller does though is to invoke |
I think that's ok-- no need to add more functionality for the purpose of being able to test something :) The main reason I suggested this was for ease of review. However again it's up to you. |
/test pull-tekton-pipeline-alpha-integration-tests |
Note that when leader election is enabled, enqueued resources will be split into buckets using an hashing function which tasks If leadership for a bucket is transferred to a different controller instance, the local cloudevent cache will be lost, similar to what happens in case of controller restart, hence the caveat in the docs. |
Thanks @lbernick - it's rebased now - only one commit in the PR :) |
@@ -137,11 +139,25 @@ func SendCloudEventWithRetries(ctx context.Context, object runtime.Object) error | |||
if err != nil { | |||
return err | |||
} | |||
// Events for Runs require a cache of events that have been sent |
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.
would you mind adding some tests in cloud_event_controller_test.go to cover the new functionality?
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.
The way I tested that is in https://github.com/tektoncd/pipeline/pull/4663/files#diff-001bb78547301c75f05f989ea355d11512f0cfa73d378d0f0c75e498cdaa6214R249-R252 by running reconcile twice and checking that events are sent the first time and not the second one.
I don't think unit tests specific to SendCloudEventWithRetries
would add much coverage, but I can try and add some if you'd like.
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.
would it be possible to just add a test case similar to this one for sending cloud events for a run?
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.
Test added, I hope this look ok.
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.
Add TestEmitCloudEvents
as well now
0af7079
to
00a8093
Compare
The following is the coverage report on the affected files.
|
00a8093
to
ffac70e
Compare
The following is the coverage report on the affected files.
|
Uhm, interesting, it looks like a flake in an existing unit test :S /test pull-tekton-pipeline-unit-tests |
/test pull-tekton-pipeline-unit-tests |
Emit CloudEvents for Runs. This is achieved by: - add a new read-only controller for Runs - emit CloudEvents only (no k8s events) on every reconcile of a Run - use an ephemeral cache to store sent events across reconcile runs. This is required because since the Runs controller only observes Runs, it does not have the context to know what was changed in the Run and though if a new event is required. The ephemeral cache logic is largely taken from the same functionality implemented in tektoncd/experimental/cloudevents Fixes tektoncd#3862 Signed-off-by: Andrea Frittoli <[email protected]>
ffac70e
to
2abc68b
Compare
The following is the coverage report on the affected files.
|
/test pull-tekton-pipeline-alpha-integration-tests |
1 similar comment
/test pull-tekton-pipeline-alpha-integration-tests |
/lgtm |
Changes
Emit CloudEvents for Runs. This is achieved by:
This is required because since the Runs controller only observes
Runs, it does not have the context to know what was changed in the
Run and though if a new event is required.
The ephemeral cache logic is largely taken from the same
functionality implemented in tektoncd/experimental/cloudevents
Fixes #3862
Depends-on #4659
Signed-off-by: Andrea Frittoli [email protected]
/kind feature
Submitter Checklist
As the author of this PR, please check off the items in this checklist:
functionality, content, code)
Release Notes