Replies: 2 comments
-
My current feeling would be to implement solution 1 + making that field a requirement in the jsonschema |
Beta Was this translation helpful? Give feedback.
0 replies
-
As a first iteration, I am just enforcing |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Description
The parameter
pipelineid
is quite central to Updatecli. It allows Updatecli to identify the same update pipeline accross multiple Updatecli execution or between manifest describing the same pipeline.I tried multiple approaches to generate that field automatically but all of them had bad side effects...
=> How does it work?
By default, if unspecified, Updatecli generates a hash based on the manifest file content as described on
updatecli/pkg/core/config/main.go
Line 102 in 9344acd
This means that if we change anything within the manifest like a credential or version then the pipelineid is updated which is considered as a new pipeline.
Consequences are multiple, we may create multiple pullrequest with the same content. We may report multiple pipeline to udash with the same content.
Until today, the only reliable way to have aa clear identifiable pipeline is to set this field to an arbitrary value as stated in #1159
I am now considering making that field mandatory, similar to the field "name".
This could be a soft rule by enforcing this via the jsonschema perspective.
Issues somehow related to this problem:
Udash
The current blocker on the Udash application is to have a clear and identifiable pipelineid.
Having a reliable pipelineid would help, but there is one additional dimension.
Report execution is associated with one Updatecli execution. Nothing prevents us to executed a different manifest from a different manifest targeting the same pullrequest by reusing the same pipelineid.
Autodiscovery
The pipelineID for autodiscovery is influenced by different rules.
updatecli/pkg/core/engine/autodiscovery.go
Line 150 in 9344acd
Solution 1:
Unless pipelineid is set. we generate a hash based on the pipeline name
The pipeline name is probably the only field with less chance to be updated while providing valuable information.
Solution 2:
Unless pipeline is already set, we generate an error and fail the pipeline
Solution 3:
Unless pipeline is already set, we display a Warning message and continue as is.
Solution 4:
Retry the approach describe in #1395
Beta Was this translation helpful? Give feedback.
All reactions