OK, so here are two diagrams that show pipeline statuses for all the situations I'm aware of after reading the documentation. My comments for the diagrams: 1) I assumed trigger type doesn't matter at all. 2) PipelineNotificationService / Pipeline / Stage are not names of classes but abstract entities. 3) Pipeline status should not indicate success/failure, because it means different things to different people/projects (for example "success" may be: all stages green, last stage green, all stages green before manual intervention, etc.). Success/failure definition should be left to a notification receiver. 4) Pipelines triggered by stages from other pipelines are nothing special.
Simplest scenario, one stage: <https://lh3.googleusercontent.com/-oR5_6BSMszo/WUmjcfPXqII/AAAAAAAAAi0/0C1AJsmjiJIgW3_NXmKePmqB7tR1SYRowCLcBGAs/s1600/OneStage.png> Second scenario, two stages (or more): <https://lh3.googleusercontent.com/-kwuylRqy07Q/WUmjyt8IDoI/AAAAAAAAAi4/YRWCPojptXMmvTFedljrev8ilM2M7UjcQCLcBGAs/s1600/TwoStages.png> If you can see that I omitted some scenario, please tell me. I propose that "pipeline-status" notification JSON be almost identical to the response of get-pipeline-instance <https://api.gocd.org/current/#get-pipeline-instance>. I would add two fields: { "build_cause": { "approver": "", "material_revisions": [ { "modifications": [ { "email_address": null, "id": 7225, "modified_time": 1435728005000, "user_name": "Pick E Reader <[email protected]>", "comment": "my hola mundo changes", "revision": "a788f1876e2e1f6e5a1e91006e75cd1d467a0edb" } ], "material": { "description": "URL: https://github.com/gocd/gocd, Branch: master", "fingerprint": "61e2da369d0207a7ef61f326eed837f964471b35072340a03f8f55d993afe01d", "type": "Git", "id": 4 }, "changed": true } ], "trigger_forced": false, "trigger_message": "modified by Pick E Reader <[email protected]>" }, "name": "PipelineName", "natural_order": 1, "can_run": false, "comment": null, *"status" : "Scheduled",* *"environment_variables": [TASK=1234],* "stages": [ { "name": "stage1", "approved_by": "changes", "jobs": [ { "name": "jsunit", "result": "Passed", "state": "Completed", "id": 1, "scheduled_date": 1398332981981 } ], "can_run": false, "result": "Passed", "approval_type": "success", "counter": "1", "id": 1, "operate_permission": false, "rerun_of_counter": null, "scheduled": true } ], "counter": 1, "id": 1, "preparing_to_schedule": false, "label": "14.1.0.1-b14a81825d081411993853ea5ea45266ced578b4" } It's CRUCIAL that "pipeline-notification" contains *environment_variables *one can schedule a pipeline using the schedule <https://api.gocd.org/current/#scheduling-pipelines> request and pass arbitrary values that are specific for that schedule and use them in a notification plugin to call back. Maybe not all of the fields are needed in the above JSON are needed, I'm open to suggestions. *status *field should probably be called "state" to keep consistency with "stage-status" notification. I hope this clarifies what I want to do. I'm willing to try implementing this notification if you decide it would benefit GoCD users. Personally, I think this is very useful for writing plugins that integrate GoCD with tracking or monitoring tools. It's 1AM here and I'm going to sleep. Thanks, Krzysztof Szatan W dniu wtorek, 20 czerwca 2017 23:57:47 UTC+2 użytkownik Krzysztof Szatan napisał: > > I think we could make "pipeline-status" notifications that are going to > solve the problems I've mentioned. I'm working on sequence diagrams at this > very moment to show you how I think it should work in various scenarios. > > Thanks, > Krzysztof Szatan > > W dniu wtorek, 20 czerwca 2017 22:38:23 UTC+2 użytkownik Aravind SV > napisał: >> >> On Mon, Jun 19, 2017 at 9:39 AM, Krzysztof Szatan <[email protected]> >> wrote: >> >>> On 19 June 2017 at 14:42, Aravind SV <[email protected]> wrote: >>> >>>> My question would be: When do you send a "pipeline-status" >>>> *notification*? Let's assume three stages, with the third stage being >>>> manual. Do you send one as soon as the second stage completes, because the >>>> third is manual? Do you then send another one for the *same pipeline >>>> instance* when the third stage is allowed to go through and completes? >>>> Two pipeline-status notifications for the same run? >>>> >>> First of all, thanks for taking your time to talk this through. In your >>> case I would see three notifications for the same run: >>> 1) Right after pipeline schedule there would be a "pipeline-status" >>> notification with a "scheduled" or "started" status. >>> 2) When the pipeline progress stops because of a manual stage there >>> would be notification with status named "stopped". "stage-status" >>> notifications could be used to decide whether pipeline was stopped because >>> manual intervention is required or because one of the stages failed. >>> 3) When the last stage finishes successfuly there would be "finished" >>> status, meaning all the stages were run. >>> >> >> Ok, I understand. Some of it might be a little tricky. If a stage is >> manual, then it doesn't even get considered. So, sending a stopped would be >> hard. Of course, nothing is impossible. :) >> >> >> I'm writing this off the top of my head right now so there are probably >>> some corner cases to be taken care of, like manual re-run of a stage. I'm >>> trying here to figure out what would make sense and what not in the context >>> of GoCD conventions and design. >>> >> >> Yes, things like a rerun, etc. will need to be considered. >> >> >> >> >>> This would also solve my problem with deciding whether pipeline run is >>> complete but seems out-of-place in "stage-status" notification that IMHO >>> should only have information about one stage. >>> >> >> Yes, that makes sense. >> >> >> >>> That's not all, though. I'll try to reiterate my original problem: >>> 1) From the notification point of view I have no means to tell whether >>> all the stages in pipeline where run or not. >>> 2) "stage-status" notification lack information about enviroment >>> variables and parameters used when scheduling a pipeline. Stage variables >>> can override pipeline variables, so they should be reported separately. My >>> use case is this: I schedule a pipeline with PHID variable that I'd like to >>> use in the notification plugin to update appropriate object in Phabricator. >>> Without this, notifications are useless. >>> >> >>> That's why 'pipeline-status' notification would be more complex than a >>> simple "success/failure" string as you've already stated. Ideally, the >>> notification would contain all the information about pipeline instance that >>> don't pose a security risk. Something like get-pipeline-instance >>> <https://api.gocd.org/current/#get-pipeline-instance> request. >>> >> >> I think trying to stuff the notification with more and more information >> is going to be tricky. We'll never know when to stop, I feel and we might >> end up exposing too much information to the plugin. I think the solution >> includes a better controlled approach to fetching data from the pipeline >> instance API, without having to provide credentials. You had asked about >> the goApplicationAccessor and whether it can be extended. An approach like >> that is what I was thinking about. However, I would like to deprecate the >> accessor and move to something more generic. >> >> The idea is to move away from java plugins and maybe towards a websocket >> connection-based communication between the plugin and the server. That's >> why most of the messages going back and forth are in JSON. The >> goApplicationAccessor is a bit of a problem since it is Java-specific in >> the way it works now. >> >> I know this needs work but there's limited capacity and I haven't >> prioritized this yet. The solution I can think of currently involves >> setting up an account (with a view-only user, say) which you can provide to >> your plugin, so that it can make a get-pipeline-instance API request. It >> would be nice if the plugin could make an authenticated call without having >> to provide it. >> >> Cheers, >> Aravind >> > -- You received this message because you are subscribed to the Google Groups "go-cd" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
