Thank you David for the helpful advice. On Thursday, 8 February 2018 13:20:47 UTC+10, David Rice wrote: > > > On Wed, Feb 7, 2018 at 6:53 PM danielle.90 <[email protected] > <javascript:>> wrote: > >> Is this design possible with GoCD? >> >> Our first challenge. >> >> 1. Splitting the build pipeline up by files within the GIT commit. For >> example, For every file in the git commit, we want to start a new, separate >> pipeline instance to process each file individually. >> > > No. GoCD respects the atomicity of each material as we see it as critical > to good pipeline design. The atomic boundary of a change set sets and > expectation for what should reasonably work. I don’t see how pulling a > single file out of a change set could result in something that is intended > or actually works, so think I might must be misunderstanding what your team > is trying to do. >
Ok I think we can live with that. To clarify what we are doing, we are building an ArcGIS Server map publishing pipeline. We only want to 'patch' new or changed maps, instead of re-publishing the entire catalogue of maps (~200 of them). So, patching all changed maps as per a commit atomically will work for us. The reason we would prefer to split the work into sub-pipelines however is that because each published map requires a isolated QA workflow. We want maps that pass validation to go to production, maps that fail to go into QA. We don't want the failures to be blocking. > > and; >> >> 2. Can we use if/else logic in our pipeline? We need to have logic in our >> pipeline that will run different stages based on a condition. I.e. if build >> stage fails, go to QA\QC stage, if build passes, go to deploy stage >> > > A GoCD job can execute an optional set of tasks on failure. This is > typically for cleanup. But there is no suppprt of conditional stage > execution based upon failure. GoCD supports the notion that a broken > pipeline should stop the production line. And, of course, GoCD can notify > your team when a pipeline fails. > > Ok that helps. I was thinking about a failed pipeline as something that could be recovered and resumed by a manual QA process. Now I see that a failed pipeline should remain failed, and that the QA step should result in a new pipeline instance being run. -- 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.
