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

[Bug] multi apps #14

Open
gilzow opened this issue Jan 31, 2023 · 2 comments
Open

[Bug] multi apps #14

gilzow opened this issue Jan 31, 2023 · 2 comments
Assignees

Comments

@gilzow
Copy link
Collaborator

gilzow commented Jan 31, 2023

In a multiapp situation, each app can have its own .platform.app.yaml config file, and therefore define its own source operation definitions. The toolkit is currently configured to start at PLATFORM_SOURCE_DIR which in most instances is the root location of the project's repository. The initial idea was we could start there and then scan down all directories to find package markers and run updates for each one we found. The challenge is that the source operation environment is built based on the application build type. This means that in many situations, the needed applications are not present to run more than one type of update.

For example, in a node.js application environment, we probably will not have composer installed. Or in a php application, we won't have the correct node version available, and/or have yarn installed.

This means that currently, a source operation in a multi application project will fail because one or more of the needed package manager types will be missing.

Since a multiapp can have their own source operations defined, we could switch and go back to using PLATFORM_APP_DIR instead. This start us in the root of the application instead of the repository. From my testing, if two (or more) applications have the same source operation with an identical name, it will run them sequentially, and not in parallel.

Maybe instead of operating from PLATFORM_SOURCE_DIR we need to pass in PWD from where the source operation starts, and have it scan starting from that location?

@gilzow gilzow self-assigned this Jan 31, 2023
@gilzow
Copy link
Collaborator Author

gilzow commented Jan 31, 2023

correction: we can't use PLATFORM_APP_DIR. During a source operation, in a multiapp, the contents of PLATFORM_APP_DIR are not the same as the contents of PLATFORM_SOURCE_DIR/<sub-app>. In my experiments so far, the contents of PLATFORM_APP_DIR is :

    drwxr-xr-x  4 web  web   36 Jan 31 19:46 .
    drwxr-xr-x 23 root root 333 Dec  6 11:46 ..
    drwx------  3 web  web   25 Jan 31 19:46 .config
    drwxr-xr-x  4 web  web   47 Jan 31 19:46 .global

@gilzow
Copy link
Collaborator Author

gilzow commented Jan 31, 2023

Alternatively, we could check for the presence of the package manager application (eg composer) before we begin the update process and only proceed with the update if it is installed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant