Add build strategy labels to task run #465
Conversation
BTW, Matthias, I still have a question, can you give an example, once we add these labels to the taskrun and taskrun pod, how can you use it in a monitoring system better? Or it is just easily for checking a taskrun/pod easily by manual? |
Consider the use case that you have multiple cluster build strategies for Kaniko builds to address different sizing. Now you want to see whether this one Kaniko cluster build strategy sizing is correct. You need to see all builds done with exactly that cluster build strategy in order to evaluate the results. At the end, you would use something like this:
|
In theory the label names should *not* change during runtime. Make the label name constants.
The `buildstrategy_types.go` contains code that is common and should be externalised. Move common code that applies to both kinds of strategies into a separate file.
There are two build strategies: The namespaced build strategy and the cluster build strategy. They have some things in common, but are two types. This can result in duplication in code to support both strategies in a function. Introduce strategy interface that encapsulates the common things.
Change function `GenerateTaskRun` to use the build strategy interface rather than the build steps in order to be more flexible for future changes.
Add section to add build strategy labels to the task run to include: - name of the build strategy - generation of the build strategy Based on the name of the build strategy label, it can further be used to differentiate between namespace based or cluster based build strategies.
|
let me take a look on this today |
|
/approve |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: qu1queee 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 |
When monitoring a system that uses https://github.com/shipwright-io/build, it would be helpful to make that the build work load can be identified very easy and correctly. At the moment, there is no direct way to differentiate between a buildrun that uses Kaniko or Buildpacks from a purely Kubernetes point of view by just looking at the actual task run pod.
Suggestion: Add more labels to the task run and therefore the task run pod to help to identify the respective work load.
In order to keep the symmetry with
build, andbuildrun, the new labels would come as the same type of pair with a name and the generation.To achieve this in code while not introducing additional code duplication, I decided to introduce an interface to encapsulate the common elements of both BuildStrategy and ClusterBuildStrategy. In theory, this could later help to reduce some code duplication that are in the code to date.