-
New Feature
-
Resolution: Fixed
-
Major
-
None
-
Platform: All, OS: All
It would be great if Hudson support more than one build schedule per project
each with different target possible.
Let me describe my issue.
We are using Hudson to do continuous builds of our projects and ocasionally to
do "release:perform" build of Maven Release Plugin.
With current Hudson we need to setup two "different" projects: "My
Project-SNAPSHOT" and "My Project-RELEASE" that differs only with maven goal
called (and the goal parameters).
I would like to see it as two different schedules, one "Poll SCM" with "mvn
package" target and second manual with "release:perform -D...".
One could setup "mvn site:deploy" nightly as a third job, etc.
It might be very usefull and keep all project activities under one Hudson
Project hood instead of many semi-different separate projects (with manual labor
required to keep them in sync).
[This is how Continuum does it and it works just fine. :-) ]
[JENKINS-346] many schedules per project
syvalta
added a comment - I think this issue is related to:
https://hudson.dev.java.net/issues/show_bug.cgi?id=1228 (it's unfortunate that
we don't have "related to" field like in jira...)
What I would call the ultimate solution:
- multiple maven invocations per schedule
- multiple schedules per project
syvalta
added a comment - I think this issue is related to:
https://hudson.dev.java.net/issues/show_bug.cgi?id=1228 (it's unfortunate that
we don't have "related to" field like in jira...)
What I would call the ultimate solution:
multiple maven invocations per schedule
multiple schedules per project
syvalta
added a comment - > - multiple maven invocations per schedule
To add, that is not strictly necessary, because you could add the same schedule
multiple times with different target. However, that would require some ordering
guarantees, for example when the second invocation requires the first one to be
complete. So, also allowing multiple invocations per schedule might be a more
elegant solution.
syvalta
added a comment - > - multiple maven invocations per schedule
To add, that is not strictly necessary, because you could add the same schedule
multiple times with different target. However, that would require some ordering
guarantees, for example when the second invocation requires the first one to be
complete. So, also allowing multiple invocations per schedule might be a more
elegant solution. 
mdonohue
added a comment - This sounds like a more specific instance of issue 3157
-
-
- This issue has been marked as a duplicate of 3157 ***
-
mdonohue
added a comment - This sounds like a more specific instance of issue 3157
This issue has been marked as a duplicate of 3157 ***
syvalta
added a comment - I don't think this is duplicate of 3157. You could use 3157 as a workaround for
this, but it's really a different thing.
syvalta
added a comment - I don't think this is duplicate of 3157. You could use 3157 as a workaround for
this, but it's really a different thing. syvalta
added a comment - Not a duplicate. Multiple schedules in one project is a different thing than
having multiple projects inheriting settings from parent.
syvalta
added a comment - Not a duplicate. Multiple schedules in one project is a different thing than
having multiple projects inheriting settings from parent. 
chinna gangarum
added a comment - I thought cronjob type list takes multiple entries, if not probably that may be good starting point. Anyway I also have interest and need in this feature/.
chinna gangarum
added a comment - I thought cronjob type list takes multiple entries, if not probably that may be good starting point. Anyway I also have interest and need in this feature/. 
Laurent Denanot
added a comment - In my opinion, one way to achieve this might be to rework the Batch Tasks plugin so that it allows for associating multiple, distinct goals or script executions (with distinct schedules) to a particular job (given that the batch tasks already share the job's workspace and config properties).
Maybe ALL schedules (with associated goals / script executions) of a job should actually be defined as distinct 'batch tasks'.
Another idea would be to allow for defining global batch tasks that could then be associated with any job (enabling for instance to define common goals for compiling projects, deploying them and performing Sonar analysis on them... A bit like 'build definitions' in Apache Continuum..
That would also be a good opportunity to add much needed missing features to the Batch Tasks plugin, such as the ability to cancel or kill a batch task...
See issues JENKINS-3615, JENKINS-3551, JENKINS-993, and JENKINS-992.
Laurent Denanot
added a comment - In my opinion, one way to achieve this might be to rework the Batch Tasks plugin so that it allows for associating multiple, distinct goals or script executions (with distinct schedules) to a particular job (given that the batch tasks already share the job's workspace and config properties).
Maybe ALL schedules (with associated goals / script executions) of a job should actually be defined as distinct 'batch tasks'.
Another idea would be to allow for defining global batch tasks that could then be associated with any job (enabling for instance to define common goals for compiling projects, deploying them and performing Sonar analysis on them... A bit like 'build definitions' in Apache Continuum..
That would also be a good opportunity to add much needed missing features to the Batch Tasks plugin, such as the ability to cancel or kill a batch task...
See issues JENKINS-3615 , JENKINS-3551 , JENKINS-993 , and JENKINS-992 . 
rewording subject