Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-51856

Job loading and JCasC conflicts: Introduce new Milestone between EXTENSIONS_AUGMENTED and JOBS_LOADED

    • jenkins-2.220

      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.

          [JENKINS-51856] Job loading and JCasC conflicts: Introduce new Milestone between EXTENSIONS_AUGMENTED and JOBS_LOADED

          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.

          Oliver Gondža added a comment - 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.

          Francisco Fernández added a comment - https://github.com/jenkinsci/jenkins/pull/4450

            fcojfernandez Francisco Fernández
            oleg_nenashev Oleg Nenashev
            Votes:
            5 Vote for this issue
            Watchers:
            11 Start watching this issue

              Created:
              Updated:
              Resolved: