-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Adds support for readiness probe #1322
base: master
Are you sure you want to change the base?
Adds support for readiness probe #1322
Conversation
0ab2f8b
to
f093342
Compare
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.
Are you aware you can already do this with the yaml syntax? The container liveness probe was added 6 years ago and it wasn't available then.
Keeping track of all new fields in Kubernetes is a never-ending game, I don't believe there is much value in adding 1-to-1 mappings to the plugin.
@@ -81,6 +81,14 @@ | |||
<periodSeconds>0</periodSeconds> | |||
<successThreshold>0</successThreshold> | |||
</livenessProbe> | |||
<readinessProbe> |
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.
Please revert all these test resources hunks. They represent old configuration, they must not be modified in order to let tests pass.
/** | ||
* Created by geanpalacios on 15/02/23. | ||
*/ | ||
public class ContainerReadinessProbe extends AbstractDescribableImpl<ContainerReadinessProbe> implements Serializable { |
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.
Looks identical to ContainerLivenessProbe
.
I would suggest to rename ContainerLivenessProbe
to ContainerProbe
, and add a compatibility alias as documented in http://www.jenkins.io/doc/developer/persistence/backward-compatibility/#rename-a-class
I understand, we provision our containers on different workflows using a standard library on a need basis and not all pods are created the same or have the same, lets say, roles configuration, volumes and such for example. Having the possibility to add a readinessProbe whenever needed will allow for better container configuration/provisioning while keeping it simple enough to be maintainable |
Is this still relevant? I also prefer to use a readiness probe at the container level rather than yaml. 👍 for this feature. |
Probably, though there are standing comments that need to be addressed. |
This adds support for
readinessProbe
on containers.I have a use case that would benefit from having this.
Since
livenessProbe
support is already a thing, I took from #158 to addreadinessProbe
related changes.