2012/10/26 Max Spring <
[hidden email]>:
> This is what I'd need:
> - Discard Old Builds
This is already a part of the base Job class.
> - Build parameters
ParametersDefinitionProperty is a JobProperty, which can work with any
Job, but ParametersDefinitionProperty opt to only work with
AbstractProject. Maybe I should relax this to work with BuildableItem.
> - Disable Build
> - All Build Triggers
This needs to be added.
> - All from Advanced, with the exception of "Use custom workspace"
I haven't checked them all, but much of them needs to be added.
Fortunately, configuration fragments of these are packaged as tag
files, making it easier to add them.
> - Post-build Actions
> - Build other projects
> - E-mail Notification
These are Publishers (which are BuildSteps), and I touched on them in
my previous e-mail.
> How would enhancements coming from other plugins show up in my job type?
It depends on the form of enhancements. For example, JobProperty can
work with arbitrary Job subtypes, so other plugins can add those (for
exampel to associate additional metadata with jobs.) Your AsyncJob
subtypes can define additional extension points, just like
AbstractProject defines SCM extension point. How you interact with
those is entirely up to you.
> How can I fail / "abort" the execution? (red state, grey state)
> Right now, all I can do is calling markCompleted() which leads to a
> successful state.
Fixed.
> On 10/26/2012 04:58 PM, Kohsuke Kawaguchi wrote:
>>
>> 2012/10/26 Max Spring <
[hidden email]>:
>>>
>>> This is cool. I'm able to run the test code.
>>>
>>> How would I add more configuration elements?
>>>
>>> How can I "inherit" most of the configuration elements from a free-style
>>> job
>>> type?
>>> E.g. the trigger elements and the post-build elements could make sense in
>>> the workflow context, too.
>>> Build parameter, cleanup definition, etc.
>>
>>
>> You'd basically have to cut&paste from AbstractProject.
>>
>> Many of these things are tied to the AbstractProject semantics of
>> synchronous execution, so they'll be unlikely to work with this. For
>> example, Builder, Publisher, SCM and so on all assume the model that
>> doesn't make sense for this.
>>
>> So let's see, what do you want. Trigger. What else?
>>
>> Maybe there's an opportunity to introduce additional type variable so
>> that BuildSteps can opt to work on AsyncRun (or other types, such as
>> ExternalRun), much like JobProperty subtypes can choose what subtypes
>> of Job it can work with.
>>
>>> The build duration is not properly captured.
>>> It should be the entire time a build is active.
>>
>>
>> Ah yes, thanks, I'll fix this.
>>
>>> Interesting:
>>>
>>> - The state of an async job "survives" a Jenkins restart.
>>>
>>> - I can launch more than one async job (that's what I want).
>>> I can see that in other contexts this should be configurable.
>>
>>
>> It already is. See AsyncJob.isConcurrentBuild()
>>
>>> Maybe a callback "boolean canStart(...)"?
>>> If it says false, the job build request gets into the build queue.
>>> I guess there's no need for me to look into the Drools plugin.
>>>
>>> -Max
>>>
>>>
>>>
>>> On 10/26/2012 11:56 AM, Kohsuke Kawaguchi wrote:
>>>>
>>>>
>>>> I implemented an abstract subtype of Job/Run that can be used to model
>>>> external asynchronous execution. See [1,2].
>>>>
>>>> While asynchronous process is ongoing, additional lines can be written
>>>> to console. When it's done, you call the markCompleted() method
>>>> to really end the build.
>>>>
>>>> The original driver for this effort was the Jenkow plugin, which wants
>>>> to capture the execution of a workflow as a build,
>>>> but I think it's an useful building block for other plugins.
>>>>
>>>> The plugin has an example of how to use these base types in its
>>>> src/test/java.
>>>>
>>>> [1]
https://wiki.jenkins-ci.org/display/JENKINS/Async+Job+Plugin>>>> [2]
https://github.com/jenkinsci/async-job-plugin>>>
>>>
>>>
>>
>>
>>
>
--
Kohsuke Kawaguchi
Locked
