Allow adding jenkins job metadata to the pods using the KubernetesComputer extenion point #383
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
KubernetesComputer creation is delegated to a factory that provides an extention point. This way, users will be able to provide their own KubernetesComputer implementations.
Vlatombe
approved these changes
Oct 22, 2018
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Kubernetes Computer ExtensionPoint
Similar to #238, we would like to add metadata of the running jenkins jobs to
the pods.
Ideally we would like to have the JOB_NAME, BUILD_NUMBER, BUILD_TAG (of which
may or may not be meaningful) available in the pods. Unlike #238, we
would like to use labels not annotations as it is easier to correlate those in
prometheus using the kube_node_labels series.
In our discussions we've realized that the display name of a job may differ
based on the job type and our naming scheme would only hold for certain jobs
and it is difficult to come up with a generic solution (especially keeping in
mind that label values can only use the following chars :[a-z0-9A-Z], dashes
(-), underscores (_), dots (.)).
One of the solutions we can think of is to create an extension point that will
allow different KubernetesComputer implementations. I've tried to reuse the
implementation in the refactoring of PlanningNode but i also feel that having
multiple providers of KubernetesComputer may lead to ambiguous class
resolution. A better approach could be to manage/activate KubernetesComputer
providers from the plugin configuration.
I can probably work on this further to get at least JOB_NAME and job status in
with the default KubernetesComputer implementation (similar to #238) and focus on the not so
generic requests (BUILD_TAG, BUILD_NUMBER) on a separate plugin that will use
the extension point provided by this change.