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
Tentacle always extracts the package to a generated staging folder, such as:
C:\Apps\Environment\PackageName\1.0.0
When customers use the custom installation directory option, they can have the files copied to another location during deployment:
C:\MyApp
In the past, when invoking PowerShell scripts, we used to search the generated staging folder for scripts, then see if they existed in the target directory before invoking. But recently during refactoring this was changed so that we search under the target folder instead. Since the target folder may contain a lot more files, this search can take much longer.
We should revert this to the old behaviour.
The text was updated successfully, but these errors were encountered:
This thread has been automatically locked since there has not been any recent activity after it was closed. If you think you've found a related issue, please contact our support team so we can triage your issue, and make sure it's handled appropriately.
lockbot
locked as resolved and limited conversation to collaborators
Nov 28, 2018
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
kind/bugThis issue represents a verified problem we are committed to solving
Tentacle always extracts the package to a generated staging folder, such as:
When customers use the custom installation directory option, they can have the files copied to another location during deployment:
In the past, when invoking PowerShell scripts, we used to search the generated staging folder for scripts, then see if they existed in the target directory before invoking. But recently during refactoring this was changed so that we search under the target folder instead. Since the target folder may contain a lot more files, this search can take much longer.
We should revert this to the old behaviour.
The text was updated successfully, but these errors were encountered: