Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactoring of the admin/autoupgrade directory structure #1156

Open
wants to merge 2 commits into
base: dev
Choose a base branch
from

Conversation

M0rgan01
Copy link
Contributor

@M0rgan01 M0rgan01 commented Feb 4, 2025

Questions Answers
Description? see below
Type? improvement
BC breaks? no
Deprecations? no
Fixed ticket? -
Sponsor company -
How to test? -

This PR reorganizes the admin/autoupgrade directory structure to improve temporary file management and prevent accidental overwriting of local releases.

Changes introduced:

  • The download folder no longer stores the downloaded release in online mode and is no longer erased in certain scenarios, preventing the loss of locally stored releases.
  • The latest folder, which contained the extracted destination release, has been renamed to files and moved to tmp/.
  • A new tmp/releases folder has been created to store the downloaded release in online mode.
  • A new tmp/modules folder has been created to store module ZIP files and migration scripts (previously located at the root of tmp/).
  • Module migration scripts are now deleted at the end of the update process.

These changes enhance the reliability of the update process and optimize the organization of temporary files.

Directory structure before/after:

Before:

admin/autoupgrade/
 ├── download/              (contained the downloaded release and local archives)
 ├── latest/                (contained extracted destination release)
 ├── tmp/                   (contained module zip files and migration scripts)

After:

 admin/autoupgrade/
 ├── download/              (no longer stores downloaded releases, is now only present for local archives)
 ├── tmp/
 │   ├── files/             (previously "latest", deleted at the end of the update process)
 │   ├── releases/          (stores downloaded releases in online mode, emptied at the end of the update process)
 │   ├── modules/           (stores module zip files and migration scripts, emptied at the end of the update process)

@M0rgan01 M0rgan01 added this to the 7.0.0 milestone Feb 4, 2025
@M0rgan01 M0rgan01 force-pushed the download-online-dev branch from 084c4d6 to 8804419 Compare February 4, 2025 13:30
@M0rgan01 M0rgan01 marked this pull request as ready for review February 4, 2025 14:12
@M0rgan01 M0rgan01 closed this Feb 4, 2025
@M0rgan01 M0rgan01 reopened this Feb 4, 2025
@Hlavtox
Copy link
Contributor

Hlavtox commented Feb 4, 2025

@M0rgan01 Would it be possible to move these files into the folder of the module, or a var directory?

Why I ask - we run integrity checks on our shops every night and we have to whitelist these files as they could change depending on if autoupgrade is installed, I think that the admin directory shouldn't really change.

@M0rgan01
Copy link
Contributor Author

M0rgan01 commented Feb 4, 2025

@Hlavtox We actually asked ourselves this question. We use this folder because we are forced to do so for several technical reasons, but also to remain compatible with old versions (not to force users to move their backup / local archives) but also to be able to consult the logs by a URL hidden behind the admin folder.

For v7 it will stay like this but it is not excluded that it will change in the future

Comment on lines 94 to 95
const FILES_PATH = 'files';
const FILES_DIR = 'files/';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't these constants be called

Suggested change
const FILES_PATH = 'files';
const FILES_DIR = 'files/';
const TMP_FILES_PATH = 'files';
const TMP_FILES_DIR = 'files/';

like the 3 next ones? As they are all subdirectories of the tmp/ folder.

case self::TMP_MODULES_DIR:
return $this->getProperty(self::TMP_MODULES_PATH) . DIRECTORY_SEPARATOR;
case self::TMP_RELEASES_DIR:
return $this->getProperty(self::TMP_PATH) . DIRECTORY_SEPARATOR . 'releases' . DIRECTORY_SEPARATOR;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shall we keep the consistency of having two properties for each folder?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For me, it's a matter of need; it's not necessary for every folder to always have a constant path and another directory.

$tmpModulePath = $this->container->getProperty(UpgradeContainer::TMP_MODULES_PATH);
if ($this->container->getFileSystem()->exists($tmpModulePath)) {
foreach (scandir($tmpModulePath) as $item) {
if ($item !== '.' && $item !== '..' && $item !== 'index.php') {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've seen these checks on another place, I wonder is a helper method for this is a good addition to the project.

Copy link
Contributor

@ga-devfront ga-devfront left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if the download folder is only used for local archives why not rename it local archives?

@M0rgan01
Copy link
Contributor Author

M0rgan01 commented Feb 5, 2025

if the download folder is only used for local archives why not rename it local archives?

For a matter of practicality and history. This folder is already present when unzipping a store, even if the module is not installed. Moreover, this prevents users from having to move or lose their archives.

@M0rgan01 M0rgan01 force-pushed the download-online-dev branch 4 times, most recently from 4924af2 to 1c7eb0f Compare February 5, 2025 09:15
@M0rgan01 M0rgan01 force-pushed the download-online-dev branch from 1c7eb0f to 64d96e5 Compare February 5, 2025 12:34
Quetzacoalt91
Quetzacoalt91 previously approved these changes Feb 5, 2025
Copy link

sonarqubecloud bot commented Feb 5, 2025

@Quetzacoalt91 Quetzacoalt91 added the enhancement Type: Improvement label Feb 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Reopened
Development

Successfully merging this pull request may close these issues.

5 participants