Replies: 1 comment
-
Update: @boherm suggested a workaround PrestaShop/autoupgrade#609 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
The problem
Hello everyone,
I would like to draw your attention to a technical problem related to Upgrade module.
It's not a new thing but I think it's important to keep written record about it. It's linked with Upgrade bug #33446
So @tleon has been investigating the above Upgrade bug.
@tleon managed to reproduce the bug by upgrading from version 1.7.8.10 to 8.1.1. He found that the upgrade failed because of a call to function
setClientOptions()
on Symfony serviceprestashop.core.circuit_breaker.guzzle.cache_subscriber
.Warning: please note that @tleon has therefore upgraded from an unpublished version to an unpublished version. Right now 8.1.1 and 1.7.8.10 are not published yet.
This call is in the src/PrestaShopBundle/Resources/config/services/adapter/news.yml file.
This file exists in PrestaShop 1.7 but was removed in 8.
When @tleon performs the Upgrade from 1.7.8.10 to 8.1.1 using the Upgrade module, the module starts. The first step performed in the upgrade process is to compare the starting version (1.7.8.10) and the target version (8.1.1) and:
So following the rule
if files were removed between 8.1.1 and 1.7.8.10, remove them
the Upgrade module should have removed the news.yml file.If the file had been removed, @tleon upgrade would have been successfull, he would not have reproduced the bug.
The step
if files were removed between 8.1.1 and 1.7.8.10, remove them
was not done :red-alert: . This is why @tleon upgrade failed.And unfortunately this is a known behavior.
Do you know how the Upgrade module compares the starting version (1.7.8.10) and the target version (8.1.1)? It uses the XML file that we build when we create the ZIP! When a new release of PrestaShop is created, we generate a ZIP and a XML file. The XML file contains checksums of all files in the ZIP. It's used to verify the integrity of the release.
And since 1.7.8.10 and 8.1.1 are unpublished versions...there are no XML files to be used.
As a result, the Upgrade module skipped the step
if files were removed between 8.1.1 and 1.7.8.10, remove them
. We had already noticed this problem a long time ago with @atomiix.So... in theory, if we publish versions 1.7.8.10 and 8.1.1 and therefore update the API used by the Upgrade module with the correct XML files, then the user who will do the upgrade in production will not have this bug. Because unlike @tleon their Upgrade module will do the step
if files have been removed between 8.1.1 and 1.7.8.10, remove them
because the Upgrade module will be able to find the XML file of these versions.But this is far from a satisfying situation
The solution
The fact that the behavior between "there is a provided XML file" and "there is no provided XML file" is a problem to be solved ... somehow 😄
Alternatives
No response
Additional context
No response
Do you plan to work on this subject?
Beta Was this translation helpful? Give feedback.
All reactions