Notification plugin stage status events don't include accurate material information for fields such as git shallow-clone
maber1993 opened this issue · comments
Issue Type
- Bug Report
Summary
During the debugging process using the official example, I noticed that there is a discrepancy between the shallowclone value in the request body and the panel configuration result after the stage status event is triggered.
Environment
Basic environment details
- Go Version:
gocd/gocd-server:v23.5.0
- JAVA Version:
17
- OS:
ubuntu 23.10
- plugin:
https://github.com/gocd-contrib/notification-skeleton-plugin
Additional Environment Details
Steps to Reproduce
cp /data/workspace/notification-skeleton-plugin-master/build/libs/notification-skeleton-plugin-0.1-SNAPSHOT.jar /data/gocd/plugins/external/
docker run -it --rm -p 8153:8153 -v /data/gocd:/godata gocd/gocd-server:v23.5.0
- Triggered pipeline
Expected Results
Actual Results
The correct configuration values are obtained in the notification plugin.
Possible Fix
Log snippets
jvm 1 | 2024-03-05 07:17:41,711 INFO [180@MessageListener for PluginNotificationMessageListener] p.c.e.n.s.c.e.n.ExamplePlugin:72 [plugin-com.example.notification.systemout] - {"pipeline":{"name":"test","counter":"1","label":"1","group":"test2","build-cause":[{"material":{"git-configuration":{"shallow-clone":false,"branch":"master","url":"https://*************/test.git"},"type":"git"},"changed":true,"modifications":[{"revision":"679ee42eb627758ac898bb1ef450636abfbfa27e","modified-time":"2024-03-04T07:30:02.000+0000","data":{}}]}],"stage":{"name":"build","counter":"1","approval-type":"success","approved-by":"changes","state":"Failed","result":"Failed","create-time":"2024-03-05T07:17:13.804+0000","last-transition-time":"2024-03-05T07:17:41.705+0000","jobs":[{"name":"build","schedule-time":"2024-03-05T07:17:13.804+0000","assign-time":"2024-03-05T07:17:25.029+0000","complete-time":"2024-03-05T07:17:38.365+0000","state":"Completed","result":"Failed","agent-uuid":"ce1c2508-2373-44fa-9b4b-fdfbe3b7d2c2"},{"name":"build2","schedule-time":"2024-03-05T07:17:13.804+0000","assign-time":"2024-03-05T07:17:39.383+0000","complete-time":"2024-03-05T07:17:41.705+0000","state":"Completed","result":"Passed","agent-uuid":"ce1c2508-2373-44fa-9b4b-fdfbe3b7d2c2"}]}}}
-->
Code snippets/Screenshots
Any other info
Yeah, these notifications appear to be based on data captured in the database for an individual pipeline run; and I suspect the material specific values such as shallow-clone
are not captured for every individual stage run, yet still misleadingly included in the serialized configuration.
Do you have a need specifically for this field in a custom plugin you are writing, or just something weird you noticed?
Yeah, these notifications appear to be based on data captured in the database for an individual pipeline run; and I suspect the material specific values such as
shallow-clone
are not captured for every individual stage run, yet still misleadingly included in the serialized configuration.Do you have a need specifically for this field in a custom plugin you are writing, or just something weird you noticed?
Yes, I am currently trying to develop a notification plugin. To expedite the build process, I am paying attention to the shallow-clone
.
Yes, I am currently trying to develop a notification plugin. To expedite the build process, I am paying attention to the
shallow-clone
.
For validating configuration data like this, it's possibly better to achieve this by querying the GoCD APIs for materials, rather than relying on the notification data when every stage status changes.
Yes, I am currently trying to develop a notification plugin. To expedite the build process, I am paying attention to the
shallow-clone
.For validating configuration data like this, it's possibly better to achieve this by querying the GoCD APIs for materials, rather than relying on the notification data when every stage status changes.
Yes, the API can fetch the correct status. Initially, the purpose of developing the plugin was to promptly detect when a stage fails to run. During the development process, I came across the shallow-clone parameter and planned to merge our initial detection functionality. However, it seems that this approach is not feasible at the moment.