Skip to content
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

Introduce a validating webhook for TaskDefinitions #1486

Closed
4 of 6 tasks
Tracked by #614
RealAnna opened this issue May 30, 2023 · 1 comment · Fixed by #1514
Closed
4 of 6 tasks
Tracked by #614

Introduce a validating webhook for TaskDefinitions #1486

RealAnna opened this issue May 30, 2023 · 1 comment · Fixed by #1514
Assignees
Labels
good first issue Good for newcomers
Milestone

Comments

@RealAnna
Copy link
Contributor

RealAnna commented May 30, 2023

Details

With #1421 we introduce multiple specs in the TaskDefinition CRD, so that the user can either declare a task using JS or a custom container. Since the TaskDefinition CRD is becoming more complex, we should introduce a validating webhook to alert users immediately if the CR being applyed is wrongly configured.

AC

  • use kubebuilder to generate a validation webhook for TaskDefinition (you can have a look at feat: add validating webhook for Keptn Metrics #668 to see what is needed for one)
  • the webhook verifies that Exactly one spec should be defined in a TaskDefinition, this could be a custom container spec is filled in OR a JS function spec (OR if already implemented a Python function spec) but NOT both or more. Also, at least one should always be filled in for the TaskDefinition to make sense, otherwise, the job would run nothing.
  • integration test to prove the webhook works (at least one test assertions that expects failure and one that passes) you can find an example of error assertions in kuttl here

DoD

  • applying a TaskDefinitions with multiple or no runtime spec fails with a clear K8s API message

Resources

Depends on

@RealAnna RealAnna added status: ready-for-refinement Issue is relevant for the next backlog refinment operator labels May 30, 2023
@RealAnna RealAnna added this to the 0.8 milestone May 30, 2023
@RealAnna RealAnna added the good first issue Good for newcomers label May 30, 2023
@thisthat thisthat removed the status: ready-for-refinement Issue is relevant for the next backlog refinment label May 30, 2023
@geoffrey1330
Copy link
Member

I'm Interested In working on the issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

4 participants