Allow users to set custom securityContext in EventListener spec#1832
Allow users to set custom securityContext in EventListener spec#1832tekton-robot merged 1 commit intotektoncd:mainfrom
Conversation
|
The following is the coverage report on the affected files.
|
|
The following is the coverage report on the affected files.
|
|
/test pull-tekton-triggers-integration-tests |
|
@khrm: The specified target(s) for
The following commands are available to trigger optional jobs:
Use DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
/test pull-tekton-triggers-integration-tests |
|
@khrm: The specified target(s) for
The following commands are available to trigger optional jobs:
Use DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
973ffce to
f9522ca
Compare
|
The following is the coverage report on the affected files.
|
f9522ca to
f228ec3
Compare
|
The following is the coverage report on the affected files.
|
f228ec3 to
7b99756
Compare
|
The following is the coverage report on the affected files.
|
1. Users can now define their own securityContext under the EventListener YAML. 2. When is true - If the user sets a custom securityContext, it is give priority and used same. - If not, a default securityContext is applied. Signed-off-by: savitaashture <sashture@redhat.com>
7b99756 to
6f35c79
Compare
|
The following is the coverage report on the affected files.
|
There was a problem hiding this comment.
Pull Request Overview
This PR adds support for allowing users to define a custom securityContext in the EventListener spec. Key changes include:
- Removing the indirection (using pointers) for securityContext fields in tests and resources.
- Updating validation logic to include and propagate a custom securityContext.
- Aligning documentation and examples to support the new securityContext option.
Reviewed Changes
Copilot reviewed 9 out of 9 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| pkg/reconciler/eventlistener/resources/deployment_test.go | Updated tests to use direct pointer values for securityContext |
| pkg/reconciler/eventlistener/resources/deployment.go | Changed baseSecurityPolicy and related functions to use pointer types; updated securityContext assignment in Deployment creation |
| pkg/reconciler/eventlistener/resources/container.go | Modified MakeContainer to conditionally use provided securityContext or create a default one using pointers |
| pkg/apis/triggers/v1beta1/event_listener_validation.go | Adjusted field mask functions to allow custom securityContext validation |
| docs/eventlisteners.md | Updated documentation to include securityContext in examples and resource specification |
Comments suppressed due to low confidence (3)
pkg/reconciler/eventlistener/resources/deployment.go:125
- Double-check that the fallback to getStrongerSecurityPolicy is applied only when a custom securityContext is not provided. This ordering appears proper but confirm that there is no unintended nil propagation.
if (*c.SetSecurityContext && securityContext == nil) {
pkg/apis/triggers/v1beta1/event_listener_validation.go:299
- The removal of setting SecurityContext to nil in podSpecMask is intentional to allow custom security contexts. Ensure that this change is clearly explained in the release notes to avoid confusion.
out.SecurityContext = nil
pkg/reconciler/eventlistener/resources/container.go:61
- The added check and default assignment for containerSecurityContext provides a good fallback when no custom securityContext is set. Confirm that the flag c.SetSecurityContext reliably represents the user’s intent.
if (*c.SetSecurityContext && containerSecurityContext == nil) {
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: khrm The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
@savitaashture: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
|
/test tekton-triggers-unit-tests |
ex:
el-security-contextis trueChanges
Submitter Checklist
As the author of this PR, please check off the items in this checklist:
/kind <type>. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tepRelease Notes