update.php tests
gordon - February 25, 2009 - 06:25
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | update system |
| Category: | feature request |
| Priority: | normal |
| Assigned: | gordon |
| Status: | needs work |
Jump to:
Description
As I am working on creating a update.sh to allow updates to be run from the shell, or within update scripts I have create new tests which test the update system so that I will know that I don't break the current update system.
What I would like to do is also work out how to test the upgrade process from 6-7, but I think that may be too difficult, I will investigate this later.
Basically there are 4 tests that test the results from 4 different type of update.
1. Single time call successful update.
2. Multiple time call successful update.
3. A failed Updated.
4. An aborted update.
This will mean that I can test these to make sure they are all working.
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| update_test.patch | 8.38 KB | Idle | Failed: 10277 passes, 29 fails, 0 exceptions | View details | Re-test |
#1
The last submitted patch failed testing.
#2
I'm gonna guess this is incorrect handling of the url.
'update.php' isn't a standard drupal url so url('update.php') may not work properly.
The testing servers run something like example.com/checkout/update.php. My guess is that url is turned into example.com/update.php. Which doesn't work since that is the D6 install running the show.
This is an issue I have thought about before and believe I dealt with in: http://drupal.org/node/366978.
Please confirm that is the issue by running it from a local install in a folder.
#3
I know that it is not under index.php and acts a little different, but it does work. I have it going on my machine but I am having problems with the pifr not doing something.
I looked at putting them in the update/tests but decided against it because it is testing the update.php and not the update status which is what update.module is.
#4
The issue isn't with PIFR per say. It is doing its job of downloading code, applying patch, and starting tests. The problem occurs when SimpleTest is running on the machine.
The patch works on my box as well, but I'm using a virtual host: drupal.d7x.loc. Is that your case? I would like to test it more similar to a testing server which is example.com/checkout/ is your drupal root as seen from browser. If you can confirm the tests work in that manor I'll see if I can get something more out of it (as PIFR 2.x will do - working on that).
#5
I am just using localhost on my laptop. So the Drupal root for where I did the change was in http://localhost/head
#6
Do you know when PIFR 2.0 will be ready as getting you to push it though will not really work as it will then start crashing every patch once it is applied.
But what I do have will do me to get update.sh working.
#7
I hope to deploy PIFR 2 after drupalcon.
#8
Subscribe. I can help out when there is something to do. Seems like we need to get PIFR2 up as next step.
#9
Have we cleared the blockers yet?
#10
I can't remember if the new testing system has been deployed yet.
If it has I will look at updating the patch to the latest version
#11
The latest patch at #67234: Update script access rights has a fix for the update.php issue which makes it possible to successfully use it in the tests. So once that is committed, seems like it should be possible to proceed here.