You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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
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.
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 inPWD
from where the source operation starts, and have it scan starting from that location?The text was updated successfully, but these errors were encountered: