Community
Participate
Working Groups
We have p2 tests which run end-to-end scenarios including installing, updating, rollback, etc. We need to review these tests and ensure we are pointing at the Juno repos.
John, do you think that it is useful having the "install 3.5 and update to 3.6 then rollback to 3.5" tests (up to and including current versions) or should we just focus on the most recent versions?
Actually nevermind. I think I have the old scenarios all working so as long as that's the case, it is worth having them around.
I've got all the tests working and entered bug 366540 to ensure the proper Platform zip files are on the test machines so we can run them. In the meantime I have disabled the end-to-end tests as they would fail without the proper archives being available.
(In reply to comment #1) > John, do you think that it is useful having the "install 3.5 and update to 3.6 > then rollback to 3.5" tests (up to and including current versions) or should we > just focus on the most recent versions? No, I don't see any point to having that in the build, since it's not testing anything in the build itself. I think the only interesting automated test scenario is 3.7->latest build and back. We know all the scenarios on the old releases work so there isn't any value to keep testing them (and probably add a lot of extra time to our test execution)
John and I talked about this and there are 3 scenarios: 1). Use the current build's director to provision a 3.x build and then use that build to perform updates, rollbacks, etc. (basically validate that the initial install was ok) This is still a valid scenario and we should keep these tests. (End2EndTest*) 2). The FromXToY tests take a 3.5 archive, perform an update to 3.6, then perform a rollback. This is only interesting for the most recent build because that is the only place the code is changing. 3). The InstallXFromY tests take a 3.5 archive and use it to install 3.6. This is only interesting for the most recent build, as well.
Ok, i've fixed the tests and now there are less hard-coded values. As long as the properties passed in by the builder are updated, they should be ok. The tests are currently disabled until the dependent bug is fixed.
DJ, are you planning on doing anything here?
I think all the work in the tests is done. We just need the extra property value (and corresponding zip) to be set in the build and we can re-enable them.
Given the state of our builds I don't see this happening for Juno.
*** Bug 414284 has been marked as a duplicate of this bug. ***
Ping. It did not happen for Juno nor Kepler, but it definitely should be back for Luna (at least previous to current integration test).
Will not be addressed in Luna.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
This bug was marked as stalebug a while ago. Marking as worksforme. If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard tag.
