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

Properly pass context in folder's page objects

    XMLWordPrintable

Details

    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

          relates to

          Bug - A problem which impairs or prevents the functions of the product. JENKINS-37615 ATH inconsistency when querying for Jenkins instance on a page object

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Resolved
          links to

          Web Link CloudBees Internal CJP-5611

          Web Link PR-186

          Activity

            Ascending order - Click to sort in descending order
            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

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

              Dates

                Created:
                Updated:
                Resolved: