-
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
Add sidecars to Tasks #1236
Add sidecars to Tasks #1236
Conversation
The following is the coverage report on pkg/.
|
The following is the coverage report on pkg/.
|
The following is the coverage report on pkg/.
|
@@ -114,7 +114,7 @@ func TestSendCloudEvents(t *testing.T) { | |||
SendSuccessfully: true, | |||
} | |||
err := SendCloudEvents(tc.taskRun, NewFakeClient(&successfulBehaviour), logger) | |||
if err == nil { | |||
if err != nil { | |||
t.Fatalf("Unexpected error sending cloud events: %v", err) |
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.
@afrittoli I'm a little confused by this fatal message and the if
above it. Is it supposed to detect error
s or nil
s? Reads to me like it should be if err != nil
but want to check with you before I merge it like this.
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.
hm this test must start failing if you change it right?
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.
That's right - I fixed a bug in the way errors were being returned related to CloudEvents and this test started failing. Changing this test got it passing after my bug fix was introduced but I wanted to double check what the actual expected behaviour was.
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.
That was a silly double-error - mistake in the code, enforced by the test :S
Thanks for catching / fixing that!
The following is the coverage report on pkg/.
|
The following is the coverage report on pkg/.
|
/test pull-tekton-pipeline-integration-tests |
The following is the coverage report on pkg/.
|
The following is the coverage report on pkg/.
|
The following is the coverage report on pkg/.
|
/test pull-tekton-pipeline-integration-tests |
Usually due to a YAML test failure! |
/test pull-tekton-pipeline-integration-tests |
I've run the failing yaml tests locally and didn't hit any issues. |
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.
Looking great! Just a few minor comments from me
@@ -114,7 +114,7 @@ func TestSendCloudEvents(t *testing.T) { | |||
SendSuccessfully: true, | |||
} | |||
err := SendCloudEvents(tc.taskRun, NewFakeClient(&successfulBehaviour), logger) | |||
if err == nil { | |||
if err != nil { | |||
t.Fatalf("Unexpected error sending cloud events: %v", err) |
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.
hm this test must start failing if you change it right?
So the YAML tests were failing and are now fixed without intervention. I assume they were timing out because of limited resources or some similar problem 🤞 |
The following is the coverage report on pkg/.
|
The following is the coverage report on pkg/.
|
/test pull-tekton-pipeline-build-tests |
The following is the coverage report on pkg/.
|
This commit adds user-defined sidecars to the TaskSpec. A sidecar is a container intended to provide some auxiliary support to a pod's primary containers. An example usecase is a mock API server for your app to hit during testing. This commit doesn't introduce any extra lifecycle management beyond that added in #936 - sidecars will be stopped without any warning or cleanup time. At the moment I'm thinking of leaving this as-is until the sidecars KEP reaches general availability in Kubernetes.
The following is the coverage report on pkg/.
|
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
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dibyom, sbwsg 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 |
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.
Cool, nice work. It's really handy being able to specify a sidecar like this!
And thank you for catching the bug on the cloud_event code.
@@ -385,6 +433,7 @@ func TestMakePod(t *testing.T) { | |||
} | |||
}) | |||
} | |||
|
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:?
@@ -454,3 +454,84 @@ func TestUpdateStatusFromPod(t *testing.T) { | |||
}) | |||
} | |||
} | |||
|
|||
func TestCountSidecars(t *testing.T) { |
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.
Nice :)
Changes
Closes #980
This commit adds user-defined sidecars to the TaskSpec. A sidecar is a
container intended to provide some auxiliary support to a pod's primary
containers. An example usecase is a mock API server for your app to hit
during testing.
This commit doesn't introduce any extra lifecycle management beyond that
added in #936 - sidecars will be stopped without any warning or cleanup
time. At the moment I'm thinking of leaving this as-is until the sidecars
KEP reaches general availability in Kubernetes.
Design doc: https://docs.google.com/document/d/1OiV75sIqwo77QbASiItBVFVsM5gWgxvtpuc4fLcbjBs/edit
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:
Reviewer Notes
If API changes
are included, additive changes
must be approved by at least two OWNERS
and backwards incompatible changes
must be approved by more than 50% of the OWNERS,
and they must first be added
in a backwards compatible way.
Release Notes