> > > Depending on what state you want to store you should look at writing > either an extension to the build flow, or a new plugin or a combination of > both. > > The states I'd want to store are the polling status of the underlying > subversion repository related to the job,
No workspace so - this is a bit moot as you have nowhere to checkout and nowhere for jenkins to calculate the changes. However if you are checking out isn't the first thing to do something with that source code? This could either be an upstream job that then kicks the flow subsequently - in which case this information is already persisted and available for you - or its a job in the flow, in which case you can get the changes from that first job (although this would be somewhat harder to then visualize in Jenkins for the buildflow). > and the archived job results > collected from the sub-jobs. This is again already stored. The flow knows what runs it triggered. the runs know what their artifacts are. If you are wanting to see the "artifacts" of a flow in a central place to save some clicking - then some custom code is the way to go. Note - that the flow is not expected to be a groovy interpreter. It was written to perform job orchestration and as such being able to do groovy was a side effect that would be removed if it was possible. Indeed there is a severer open ticket to not run all groovy and to only allow a subset of commands to be run for security reasons. > Things that you just expect every > jenkins job to provide, and that have nothing to do with slave > availability other than needing them temporarily before you can > archive their artifacts. Sorry - archive artifacts is already handled by jenkins for the sub jobs. You are trying to bend the buildflow plugin to be something it was not intended to be. > I don't understand the point of removing > these things and then suggesting a plugin extension just to put them > back. > > Firstly you are abusing somewhat the intention of buildflow The buildflow was designed (not by me) as a **coordinator ** of jobs, as such it should not need a workspace - nor should it need to consume an executor as it shouldn't be doing anything more complex than triggering builds based on some other build state in a give order. -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
