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

Properly pass context in folder's page objects

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      Let's describe the issue with a test. Assumming we already have an injector and a JenkinsController, the following test will fail:

      Jenkins j1 = new Jenkins(injector, jenkinsController);
      FolderItem f = j1.jobs.create(FolderItem.class);
      Assert.assertSame(j1, f.jobs.getJenkins());
      

      The problem reproduced is the same described in JENKINS-37615, but specific to {{FolderItem}}s, since they are not properly receiving their context when created.

        Attachments

          Issue Links

            Activity

            mfranco Manuel Franco created issue -
            mfranco Manuel Franco made changes -
            Field Original Value New Value
            Description Let's describe the issue with a test. Assumming we already have an injector and a JenkinsController, the following test will fail:

            {code:java}
            Jenkins j1 = new Jenkins(injector, jenkinsController);
            Assert.assertSame(j1, j1.jobs.getJenkins());
            {code}

            The problem is that the jenkins instance returned by the {{getJenkins()}} method in the {{JobsMixIn}} object (actually inherited from {{PageObject}}) is not the instance that was passed as a context in the construction of this last one, but an instance that is looked up (and built if needed) using guice.

            This leads to potential inconsistencies for some operations (e.g. {{jobs.create}}) that rely on querying its jenkins instance, for example for the version number.

            Sometimes as an [external user|https://github.com/jenkinsci/acceptance-test-harness/blob/master/docs/EXTERNAL.md] of the ATH I may need to create several instances with different versions, and want each jobs mixin to know exactly to which jenkins they belong to and behave consistently.
            Let's describe the issue with a test. Assumming we already have an injector and a JenkinsController, the following test will fail:

            {code:java}
            Jenkins j1 = new Jenkins(injector, jenkinsController);
            Assert.assertSame(j1, j1.jobs.getJenkins());

            Jenkins j1 = new Jenkins(injector, jc);
                    Assert.assertSame(j1, j1.jobs.getJenkins());
                    
                    FolderItem f = j1.jobs.create(FolderItem.class);
                    Assert.assertSame(j1, f.jobs.getJenkins());
            {code}

            The problem is that the jenkins instance returned by the {{getJenkins()}} method in the {{JobsMixIn}} object (actually inherited from {{PageObject}}) is not the instance that was passed as a context in the construction of this last one, but an instance that is looked up (and built if needed) using guice.

            This leads to potential inconsistencies for some operations (e.g. {{jobs.create}}) that rely on querying its jenkins instance, for example for the version number.

            Sometimes as an [external user|https://github.com/jenkinsci/acceptance-test-harness/blob/master/docs/EXTERNAL.md] of the ATH I may need to create several instances with different versions, and want each jobs mixin to know exactly to which jenkins they belong to and behave consistently.
            mfranco Manuel Franco made changes -
            Description Let's describe the issue with a test. Assumming we already have an injector and a JenkinsController, the following test will fail:

            {code:java}
            Jenkins j1 = new Jenkins(injector, jenkinsController);
            Assert.assertSame(j1, j1.jobs.getJenkins());

            Jenkins j1 = new Jenkins(injector, jc);
                    Assert.assertSame(j1, j1.jobs.getJenkins());
                    
                    FolderItem f = j1.jobs.create(FolderItem.class);
                    Assert.assertSame(j1, f.jobs.getJenkins());
            {code}

            The problem is that the jenkins instance returned by the {{getJenkins()}} method in the {{JobsMixIn}} object (actually inherited from {{PageObject}}) is not the instance that was passed as a context in the construction of this last one, but an instance that is looked up (and built if needed) using guice.

            This leads to potential inconsistencies for some operations (e.g. {{jobs.create}}) that rely on querying its jenkins instance, for example for the version number.

            Sometimes as an [external user|https://github.com/jenkinsci/acceptance-test-harness/blob/master/docs/EXTERNAL.md] of the ATH I may need to create several instances with different versions, and want each jobs mixin to know exactly to which jenkins they belong to and behave consistently.
            Let's describe the issue with a test. Assumming we already have an injector and a JenkinsController, the following test will fail:

            {code:java}
            Jenkins j1 = new Jenkins(injector, jenkinsController);
            FolderItem f = j1.jobs.create(FolderItem.class);
            Assert.assertSame(j1, f.jobs.getJenkins());
            {code}

            The problem reproduced is the same described in JENKINS-XXX, but specific to {{FolderItem}}s, since they are not properly receiving their context when created.
            mfranco Manuel Franco made changes -
            Description Let's describe the issue with a test. Assumming we already have an injector and a JenkinsController, the following test will fail:

            {code:java}
            Jenkins j1 = new Jenkins(injector, jenkinsController);
            FolderItem f = j1.jobs.create(FolderItem.class);
            Assert.assertSame(j1, f.jobs.getJenkins());
            {code}

            The problem reproduced is the same described in JENKINS-XXX, but specific to {{FolderItem}}s, since they are not properly receiving their context when created.
            Let's describe the issue with a test. Assumming we already have an injector and a {{JenkinsController}}, the following test will fail:

            {code:java}
            Jenkins j1 = new Jenkins(injector, jenkinsController);
            FolderItem f = j1.jobs.create(FolderItem.class);
            Assert.assertSame(j1, f.jobs.getJenkins());
            {code}

            The problem reproduced is the same described in JENKINS-XXX, but specific to {{FolderItem}}s, since they are not properly receiving their context when created.
            mfranco Manuel Franco made changes -
            Description Let's describe the issue with a test. Assumming we already have an injector and a {{JenkinsController}}, the following test will fail:

            {code:java}
            Jenkins j1 = new Jenkins(injector, jenkinsController);
            FolderItem f = j1.jobs.create(FolderItem.class);
            Assert.assertSame(j1, f.jobs.getJenkins());
            {code}

            The problem reproduced is the same described in JENKINS-XXX, but specific to {{FolderItem}}s, since they are not properly receiving their context when created.
            Let's describe the issue with a test. Assumming we already have an injector and a {{JenkinsController}}, the following test will fail:

            {code:java}
            Jenkins j1 = new Jenkins(injector, jenkinsController);
            FolderItem f = j1.jobs.create(FolderItem.class);
            Assert.assertSame(j1, f.jobs.getJenkins());
            {code}

            The problem reproduced is the same described in JENKINS-37615, but specific to {{FolderItem}}s, since they are not properly receiving their context when created.
            mfranco Manuel Franco made changes -
            Link This issue relates to JENKINS-37615 [ JENKINS-37615 ]
            mfranco Manuel Franco made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            mfranco Manuel Franco made changes -
            Remote Link This issue links to "PR-186 (Web Link)" [ 14822 ]
            mfranco Manuel Franco made changes -
            Status In Progress [ 3 ] In Review [ 10005 ]
            mfranco Manuel Franco made changes -
            Status In Review [ 10005 ] In Progress [ 3 ]
            mfranco Manuel Franco made changes -
            Environment ATH 1.38 ATH 1.39
            mfranco Manuel Franco made changes -
            Resolution Fixed [ 1 ]
            Status In Progress [ 3 ] Resolved [ 5 ]
            cloudbees CloudBees Inc. made changes -
            Remote Link This issue links to "CloudBees Internal CJP-5611 (Web Link)" [ 19299 ]

              People

              Assignee:
              mfranco Manuel Franco
              Reporter:
              mfranco Manuel Franco
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: