-
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
Deprecate PipelineRun.Spec.ServiceAccountNames 🦌 #3028
Deprecate PipelineRun.Spec.ServiceAccountNames 🦌 #3028
Conversation
/kind cleanup |
2994728
to
2354446
Compare
`PipelineRun.Spec.TaskRunSpecs` already allows to specify a `ServiceAccountName` for a specific task. This marks `PipelineRun.Spec.ServiceAccountNames` as deprecated and to be removed in about 9 months. This also make sure `PipelineRun.Spec.ServiceAccountNames` are not ignored. Signed-off-by: Vincent Demeester <vincent@sbr.pm>
2354446
to
e6fe3bf
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.
/lgtm
for _, taskrunSpec := range pr.Spec.TaskRunSpecs { | ||
if _, ok := pipelineTasks[taskrunSpec.PipelineTaskName]; !ok { | ||
return fmt.Errorf("PipelineRun's taskrunSpecs defined wrong taskName: %q, does not exist in Pipeline", taskrunSpec.PipelineTaskName) | ||
} |
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 to validate taskNames!
nice! lgtm, this is an API change though so I think it needs to be approved by "more than 50% of owners", right? |
So… nothing in the API changes (aka no field is added or removed), we are just marking a field for deprecation (that we should have done when |
I agree with @dlorenc 's interpretation: i think that approving and merging this PR would be our intent to have a backwards incompatible change, even if we don't make that change in this PR. I approve - i wonder if it might be worth taking some time to examine taskRunSpecs a bit more closely, it feels like we haven't though through that area of the API carefully (for example not noticing that it repeated the info in serviceAccountNames) but that might just be me being like "i wasnt part of this so i dont like it" so 🤷♀️ . I agree that having both doesn't make sense. |
So the gist behind |
@@ -366,14 +366,23 @@ func (c *Reconciler) reconcile(ctx context.Context, pr *v1beta1.PipelineRun) err | |||
return controller.NewPermanentError(err) | |||
} | |||
|
|||
// Ensure that the ServiceAccountNames defined correct. | |||
// Ensure that the ServiceAccountNames defined are correct. | |||
// This is "deprecated". |
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: why in quotes?
I approve of this change. @pritidesai @sbwsg FYI |
Yup, I also approve. |
Looks like we're at quorom now! /approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dlorenc, jlpettersson 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 |
Changes
PipelineRun.Spec.TaskRunSpecs
already allows to specify aServiceAccountName
for a specific task. This marksPipelineRun.Spec.ServiceAccountNames
as deprecated and to be removedin about 9 months.
This also make sure
PipelineRun.Spec.ServiceAccountNames
are not ignored.Fixes #2614
Signed-off-by: Vincent Demeester vincent@sbr.pm
/cc @bobcatfish @sbwsg @afrittoli @jlpettersson
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:
See the contribution guide for more details.
Double check this list of stuff that's easy to miss:
cmd
dir, please updatethe release Task to build and release this image.
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