Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Hudson-ci/Planning/Job Templates"
| Line 1: | Line 1: | ||
| − | {{hudson|pageTitle=Planning: Job Templates}} | + | {{hudson|pageTitle=Planning: Job Templates}} |
== Overview == | == Overview == | ||
| Line 13: | Line 13: | ||
<br> | <br> | ||
| − | + | '''1. Multiple inheritence trees must be possible''' | |
| − | + | ||
| − | + | If you take a look at the job graph on [[Hudson-ci/Planning/Better Job Coordination|Better Job Coordination]] planning page, this diagram shows the jobs needed for one environment. The two create A/B jobs are similar enough that they could be templatized , so that is the first branch of the inheritence tree. The other branch is the environment specifc settings such as SCM settings. (We want each environment to use a specific version of the deployment framework and thus have to checkout different branches/tags). For us this would lead to the following templates<br> | |
| − | + | ||
| − | + | "Create_Domain" (specifies how to create a weblogic domain) --> "Create Weblogic frontend" (specifies any specialization from create domain) | |
| + | |||
| + | "Test Environment" (specifies SCM settings for the environment) | ||
| + | |||
| + | The concreate job for "create Frontend TestEnv" would then inherit from both "Create Weblogic frontend" and "Test Environment" | ||
| + | |||
| + | |||
| + | |||
| + | '''2. It should be possible to define which sections of the job config is exported in the template''' | ||
| + | |||
| + | Given the multiple inheritence above, it is important that the user has control over which sections (What is the correct term?) of the job configuration that is exported in a template. Otherwise we risk that the "Test Environment" template overwrites values specified in "Create Frontend" template | ||
| + | |||
| + | |||
| + | '''3. It should be possible to specify parameters to the template.''' | ||
| + | |||
| + | In the case from above the "Create Domain" template might specify the build steps involed such as running a script. If we assume this script takes a "domain type" paramter, then in the "Create Weblogic frontend" I want to specify that "domain type" is "frontend". Theoretically I can do this using "parametized build" plugin, but that has the effect that it presents the user with a parameter values screen whe builds are manually trigered or as part pf the "parameters" view. | ||
| + | |||
| + | While this is valuable for user provided values, template values are more of a implementation detail (as seen from the normal developer) and should remain hidden. | ||
| + | |||
| + | |||
| + | '''3. Job acting as templates should be marked as such''' | ||
| + | |||
| + | The use case is that a template will specify a trigger such as SCM polling, but given the job is only a template we do not want the trigger to actually fire. | ||
| + | |||
| + | |||
| + | |||
| + | '''4. Configuration of concrete jobs must be inheritence visible and controllable''' | ||
| + | |||
| + | When creating a concreate job, the user interface must be very explicit. | ||
| + | |||
| + | *Must be able to see which values are inherited | ||
| + | *If I have proeviously overridden an inherited value, it must be possible to revert back to the inherited value | ||
Latest revision as of 15:47, 5 September 2011
| Hudson Continuous Integration Server | |
| Website | |
| Download | |
| Community | |
| Mailing List • Forums • IRC • mattermost | |
| Issues | |
| Open • Help Wanted • Bug Day | |
| Contribute | |
| Browse Source |
|
Planning: Job Templates |
|---|
Overview
This page is for discussing the "Job Templates" feature. It is sometime also known as cascading jobs
Requirements
Details are comming later, but the high level requirements are
1. Multiple inheritence trees must be possible
If you take a look at the job graph on Better Job Coordination planning page, this diagram shows the jobs needed for one environment. The two create A/B jobs are similar enough that they could be templatized , so that is the first branch of the inheritence tree. The other branch is the environment specifc settings such as SCM settings. (We want each environment to use a specific version of the deployment framework and thus have to checkout different branches/tags). For us this would lead to the following templates
"Create_Domain" (specifies how to create a weblogic domain) --> "Create Weblogic frontend" (specifies any specialization from create domain)
"Test Environment" (specifies SCM settings for the environment)
The concreate job for "create Frontend TestEnv" would then inherit from both "Create Weblogic frontend" and "Test Environment"
2. It should be possible to define which sections of the job config is exported in the template
Given the multiple inheritence above, it is important that the user has control over which sections (What is the correct term?) of the job configuration that is exported in a template. Otherwise we risk that the "Test Environment" template overwrites values specified in "Create Frontend" template
3. It should be possible to specify parameters to the template.
In the case from above the "Create Domain" template might specify the build steps involed such as running a script. If we assume this script takes a "domain type" paramter, then in the "Create Weblogic frontend" I want to specify that "domain type" is "frontend". Theoretically I can do this using "parametized build" plugin, but that has the effect that it presents the user with a parameter values screen whe builds are manually trigered or as part pf the "parameters" view.
While this is valuable for user provided values, template values are more of a implementation detail (as seen from the normal developer) and should remain hidden.
3. Job acting as templates should be marked as such
The use case is that a template will specify a trigger such as SCM polling, but given the job is only a template we do not want the trigger to actually fire.
4. Configuration of concrete jobs must be inheritence visible and controllable
When creating a concreate job, the user interface must be very explicit.
- Must be able to see which values are inherited
- If I have proeviously overridden an inherited value, it must be possible to revert back to the inherited value