Make updater app tester friendly

[PVince81]

Currently it is close to impossible to test patches.

Testers need to download dailies, manually patch them and then hack Fetcher.php to feed the patched tarball to the updater just for testing.

It is important for developers, testers and also for community involvement to have a better way of testing changes to the updater.

I think we need to invest some time in this. It seems the current way was to put a patch in, wait for a daily to have it, then test again. This doesn't scale as one needs to wait a day to be able to test.

My suggestions, either: 1) Add a "pause" mode after the download to allow people to patch the last downloaded version for testing: https://github.com/owncloud/updater/issues/333 or 2) Make it possible to tell the updater through a debug option to use a specific tarball from the local filesystem or a given URL

@karlitschek @DeepDiver1975 @VicDeo @LukasReschke I think this is critical because without this it is very discouraging to test any changes

[PVince81]

Writing down what @LukasReschke told me I needed to do to test a PR:

[12:03:45] <lukas> download daily
[12:03:47] <lukas> apply the patch
[12:03:49] <lukas> zip the daily
[12:03:56] <lukas> go to your updater code of your existing owncloud
[12:04:01] <lukas> adjust https://github.com/owncloud/updater/blob/8b971f9631aa6a6015ead3b48c7d8c72c24860f2/src/Utils/Fetcher.php#L128-L129 to point to your zipped daily with the patch

Also, the file needs to be served by a web server, not "file://".

@LukasReschke mind explaining in which way I need to change these lines ? There are two variables "url" and "web". Should "url" be hacked to point directly to the tarball's URL ? What about "web" ?

[LukasReschke]

@LukasReschke mind explaining in which way I need to change these lines ? There are two variables "url" and "web". Should "url" be hacked to point directly to the tarball's URL ? What about "web" ?

Only URL needs to be adjusted. Web is the link to the documentation. I always change both to point to my local patched ownCloud.

[PVince81]

Another idea is to have a "debug" channel when debug mode is enabled, and have a "config.php" option to specify the URL to a dummy local channel for testing. Ideally a zip file with the said channel's metadata should be provided too (or instructions about how to set up the debug channel).

[DeepDiver1975]

As already explained by mail these days - i suggest to add an option to the Updater to pass in a local tar or ZIP.

[DeepDiver1975]

On 04/25/2016 02:09 PM, Thomas Müller wrote:

What about passing in any tarball from local? This would give us the biggest flexibility and reduce the dependency to an absolute minimum.

Furthermore - can we keep at least the last 5 daily builds on the download server?

With respect to the updater testing script - I'd prefer a bash script living in updater repo - worst case a php script is acceptable as well. Please no python-fu or any other scripting stuff.

Thanks,

Thomas

[davitol]

It would be a great enhancement for the QA team! Thank you all!!!

[PVince81]

@LukasReschke has added a config.php value to configure the update server, it's already a good step forward.

Not sure if it's enough. Moving ticket to 9.2 for further improvements.

[PVince81]

I think automated tests for this has a higher priority than facilitating manual testing.

[felixboehm]

@patrickjahns please think about a good approach for testing updates in general, including the way of updating via this app

[VicDeo]

1. possible via cli with sudo -u www-data php updater/application.php upgrade:start

2. as for facilitating manual testing (by applying patches) we can add non-extisting directory to the composer autoloader https://github.com/owncloud/updater/blob/master/composer.json#L3

   "psr-4": {"Owncloud\\Updater\\": ["src/patches", "src/"]}

   In this case patched file will be taken (if present). This would also allow to patch already released updater by placing bugfixes from the new release to this dir