Details
-
Type:
New Feature
-
Status: Resolved (View Workflow)
-
Priority:
Critical
-
Resolution: Done
-
Component/s: configuration-as-code-plugin, core
-
Labels:
-
Similar Issues:
-
Released As:jenkins-2.220
Description
In Jenkins Configuration-as-Code Plugin the initialization may happen in parallel with Job loading. It may cause various race conditions in the plugin, see https://github.com/jenkinsci/configuration-as-code-plugin/issues/280 for more details.
In order to address this case, I propose to create a new Milestone between EXTENSIONS_AUGMENTED and JOBS_LOADED. It would allow some plugins to handle extension-based functionality, e.g. to do some Jenkins preconfiguration BEFORE it starts loading jobs.
I would call it "PRECONFIGURATION_COMPLETED" or so.
Attachments
Issue Links
- is related to
-
JENKINS-61694 Groovy Hooks may run before or after JOB_CONFIG_ADAPTED
-
- Resolved
-
- links to
Activity
| Field | Original Value | New Value |
|---|---|---|
| Labels | jcasc-compatibility |
| Priority | Minor [ 4 ] | Critical [ 2 ] |
| Summary | Introduce new Milestone between EXTENSIONS_AUGMENTED and JOBS_LOADED | Job loading and JCasC conflicts: Introduce new Milestone between EXTENSIONS_AUGMENTED and JOBS_LOADED |
| Remote Link | This issue links to "configuration-as-code-plugin/issues/280 (Web Link)" [ 23021 ] |
| Component/s | configuration-as-code-plugin [ 23170 ] |
| Assignee | Francisco Fernández [ fcojfernandez ] |
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Status | In Progress [ 3 ] | In Review [ 10005 ] |
| Released As | jenkins-2.220 | |
| Resolution | Done [ 10000 ] | |
| Status | In Review [ 10005 ] | Resolved [ 5 ] |
| Link |
This issue is related to |
SAI VAMSI
made changes -
| Assignee | Francisco Fernández [ fcojfernandez ] | SAI VAMSI [ JIRAUSER132484 ] |
| Assignee | SAI VAMSI [ JIRAUSER132484 ] | Francisco Fernández [ fcojfernandez ] |
What I like even better is a way to declare, that 2 initializers has explicit ordering that needs to be respected by reactor. It is sort-of tangential to the milestone approach we are currently using, but is more flexible in the long run (as we do not have to keep adding milestones or hope race condition not worth addressing will not bite us).
In such a scheme, some prominent initializers (job load, jcasc, etc.) would be exposed as quasi-milestones for other initlizers to declare ordering on. So we can expose job-loading with a name, declare that jcasc must complete before job-loading. Then I as a developer can declare my post-init initializer must not start before jcasc has completed (while being permitted to run in parallel with job loading), etc.