This was caused by the strict comparison in \utils::IsMemoryLimitOk for the special "-1" value of memory_limit, which was added in c2f5cafa.
Fix was to change \utils::ConvertToBytes : it was returning original value when input was numeric (so if input is '-1' output was '-1') now it always returns an int (input '-1' output -1)
Some scripts are setting the memory_limit PHP option : setup, csvimport and XLSX export. This was done to avoid crashing when dealing with such large amount of data.
But sometimes we were setting the value without any prior check, so we could actually lower the memory_limit value :/
Now this memory_limit change is done using \utils::SetMinMemoryLimit, which will call ini_set if and only if the current value is lower than the one to be set.
Setup calls (setup/ajax.dataloader.php and webservices/backoffice.dataloader.php) were left as is as they weren't subject to this bug, and also they are more complex (logging done on each case).
* Remove XFrame header set in \WebPage::no_cache : not this method responsability, was confusing :/
* Remove no_cache() calls when already set in page constructor (ajax_page mainly)
* Also calls everywhere the \WebPage::no_cache method instead of setting headers manually
- new Jenkinsfile and .jenkins removal to launch phpunit/behat tests
triggered on both iTop build and push.
- N°3053 - Check XML conversion methods
- N°3057 - New build recipe
- N°3059 - Automatically set the documentation URLs
- N°3052 - Check community modules XML version against latest version
- N°3054 - Check community modules version against major version
- N°3062 - setup.css file integrity test
- N°3060 - Check consistency between the list of modules and installation.xml
- Add exclusion group for CI
- N°3061 - Automatically check the installation.xml consistency
It is quite common that the PHP interpreter that is launched in CLI is different that the one used by the webserver. So iTop code launched by CLI could run in a context that doesn't meet iTop requirements !
This adds in the following scripts the same control that is done on the setup wizard first step :
* cron.php
* backup, check-backup
* export, exportv2
* bulk import
* synchro-exec, synchro-import
If the check throws at least one error then the script is stopped with an appropriate message, and a log is made (IssueLog, Error level, CLI channel)
