On Mon, Jun 19, 2017 at 9:39 AM, Krzysztof Szatan <ksza...@gmail.com> wrote:
> On 19 June 2017 at 14:42, Aravind SV <arv...@thoughtworks.com> 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 go-cd+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
