On Wed, Mar 26, 2014 at 3:47 AM, teilo <teilo+goo...@teilo.net> wrote:
>
>> 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).
When the job is all about changes in a source repository, it just
doesn't make any sense to me to need a different job to poll the
repository then start the real work.
>> 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.
It's not stored centrally or in the right layout. The reason I want
to use build flow in the first place is to have a more flexible
version of a matrix build where the sub-jobs can do slightly different
things and then I want to collect all the build results in a different
layout where they can be committed atomically into a tag in a
subversion repository that matches the way we use svn externals for
components of other projects. And it doesn't make sense to not have
the results end up in the same job that polled the source as the
trigger.
> 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.
Yes that is unfortunate too. I think what I really want is a groovy
library equivalent of the flow dsl so I can just run a groovy step to
perform the operations I need without being a groovy expert and
without the awkward restrictions. Or just a big chunk of boilerplate
code to paste in...
>> 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.
If it doesn't handle source changes or the overall results, then it
really doesn't relate at all to what I need to accomplish. Don't
most jenkins jobs trigger on a source change and end up with archived
results at the end?
>> 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.
I guess what I need is pure groovy then. I really don't want to
clutter jenkins with trigger/collector jobs and have to keep all the
parameters coordinated and remember that you start one job but commit
the results from some other job. Is there a way to make a groovy
library available across the slaves to reduce the quantity of code you
have to enter?
--
Les Mikesell
lesmikes...@gmail.com
--
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.
