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] > <javascript:>> wrote: > >> On 19 June 2017 at 14:42, Aravind SV <[email protected] >> <javascript:>> 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.
