Files
UnrealEngineUWP/Engine/Source/Developer/Virtualization/Private/VirtualizationSourceControlBackend.h

154 lines
6.7 KiB
C
Raw Normal View History

// Copyright Epic Games, Inc. All Rights Reserved.
#pragma once
#include "IVirtualizationBackend.h"
#include "Containers/StringView.h"
class ISourceControlProvider;
namespace UE::Virtualization
{
class FSemaphore;
/**
* This backend can be used to access payloads stored in source control.
* The backend doesn't 'check out' a payload file but instead will just download the payload as
* a binary blob.
* It is assumed that the files are stored with the same path convention as the file system
* backend, found in Utils::PayloadIdToPath.
*
* Ini file setup:
* 'Name'=(Type=P4SourceControl, DepotRoot="//ABC/")
* Where 'Name' is the backend name in the hierarchy and 'ABC' is the path in the source control
* depot where the payload files are being stored.
*
* Optional Values:
* Server [string]: When set the backend will use this server address to connect to. When not
* set the backend will use the environment defaults. [Default=""]
* ClientStream [string]: Used when the payloads are stored in a stream based depot. It should contain
* the stream name to use when creating a workspace for payload submission. [Default=""]
Improved the code logic for where we submit virtualized payloads from and added some additional options. #rb PJ.Kack #jira UE-142926 #preflight 621e1f177f2803279b575764 - Now when payloads are submitted, we will submit them from within the project's saved directory (by default) this now works because we write a .p4ignore file to the submission directory which will override any additional ignore file higher up in the directory structure. -- A new utility function ::CreateSubmissionSessionDirectory was added to make sure that the directory we are submitting from has a p4ignore file. It is added in it's own scope as it is assumed that additional functionality will be added here later. - If a user wishes to choose a different location to submit from, they can override the environment variable "UE-VirtualizationWorkingDir" to provide a different location. This might be useful if the user does not have a huge amount of spare space on the disk that the project is running from. - There is also an optional entry to the ini file set up 'SubmitFromTempDir' (false by default) which when set to true will cause the system to attempt to submit the payload files from the machines temp directory instead. -- There isn't an easy way for users to override this locally, which reduces the usefulness of the option. This might be worth improving in the future although that time would be better spent removing the need for the directory in the first place. - We now try to find/create the root directory to submit payloads from when the backend is created. Failure at this point is not expected and will prevent the backend from working and so is considered an error. - Added more logging to track the session guid when submitting and to be clear about where the files are being submitted from. [CL 19197367 by paul chipchase in ue5-main branch]
2022-03-01 09:05:41 -05:00
* UsePartitionedClient [bool]: When true the temporary workspace client created to submit payloads
* from will be created as a partitioned workspace which is less overhead
* on the source control server. If your server does not support this then
* use false. [Default=True]
* WorkingDir [string]: Sets the temp location on disk where payloads are submitted from. The path can
* contain config file expansions (see ConfigCacheIni.cpp ::MatchExpansions) and
* environment variables with the format $(EnvVarName).
* [Default="%GAMESAVEDDIR%/VASubmission"]
* RetryCount [int32]: How many times we should try to download a payload before giving up with
* an error. Useful when the connection is unreliable but does not experience
* frequent persistent outages. [Default=2]
* RetryWaitTime [int32]: The length of time the process should wait between each download attempt
* in milliseconds. Remember that the max length of time that the process
* can stall attempting to download a payload file is
* RetryCount * RetryWaitTime; [Default=100ms]
* MaxConnections [int32] The maximum number of perforce connections that can be made concurrently.
* If this value is exceeded then additional requests will wait until a
* connection becomes free. Pass in '-1' to disable this feature and allow
* unlimited connections. [Default=8]
* BatchCount [int32] The max number of payloads that can be pushed to source control in a
* single submit. If the number of payloads in a request batch exceeds
* this size then it will be split into multiple smaller batches. [Default=100]
* SuppressNotifications[bool]: When true the system will not display a pop up notification when a
* connection error occurs, allowing the user to stay unaware of the error
* unless it actually causes some sort of problem. [Default=false]
* IgnoreFile [string]: Sets the name of the p4 ignore file to use. When submitting payloads we
* create a custom p4 ignore file to override any ignore settings for a project
* which allows us to submit from the saved directory which is normally prevented
* by the default ignore file. This value can be set to what ever is used by
* your perforce environment. [Default=".p4ignore.txt"]
Improved the code logic for where we submit virtualized payloads from and added some additional options. #rb PJ.Kack #jira UE-142926 #preflight 621e1f177f2803279b575764 - Now when payloads are submitted, we will submit them from within the project's saved directory (by default) this now works because we write a .p4ignore file to the submission directory which will override any additional ignore file higher up in the directory structure. -- A new utility function ::CreateSubmissionSessionDirectory was added to make sure that the directory we are submitting from has a p4ignore file. It is added in it's own scope as it is assumed that additional functionality will be added here later. - If a user wishes to choose a different location to submit from, they can override the environment variable "UE-VirtualizationWorkingDir" to provide a different location. This might be useful if the user does not have a huge amount of spare space on the disk that the project is running from. - There is also an optional entry to the ini file set up 'SubmitFromTempDir' (false by default) which when set to true will cause the system to attempt to submit the payload files from the machines temp directory instead. -- There isn't an easy way for users to override this locally, which reduces the usefulness of the option. This might be worth improving in the future although that time would be better spent removing the need for the directory in the first place. - We now try to find/create the root directory to submit payloads from when the backend is created. Failure at this point is not expected and will prevent the backend from working and so is considered an error. - Added more logging to track the session guid when submitting and to be clear about where the files are being submitted from. [CL 19197367 by paul chipchase in ue5-main branch]
2022-03-01 09:05:41 -05:00
*
* Environment Variables:
* UE-VirtualizationWorkingDir [string]: This can be set to a valid directory path that the backend
* should use as the root location to submit payloads from.
* If the users machine has this set then 'SubmitFromTempDir'
* will be ignored.
The source control settings for the VA source control connection are no longer saved to a local ini file. #rb Per.Larsson #jira UE-163834 #rnx #preflight 632d98e4b4515b7e221654ec ### Virtualization - At the moment there is no way in the editor UX to change the source control settings for the source control backend, so what ever settings are found in the global environment would be applied when the editor is first run and then saved to a config file under the <saved> directory. From this point onwards those settings would always be used when setting up the source control backend. If the settings were wrong, the first time that the editor was started, then we'd continue to use the incorrect settings even if the global enviroment was fixed. Making the backend work at that point would require that the user know about the local ini file and change the settings there. - We cannot fix this by just ignoring the ini file as it has been requested that users can add their settings there in case they want to customize things, so we just need to avoid saving to it. - Added documentation to the source control backends header file on how to set up the ini file if needed. ### Perforce - FSourceControlInitSettings now accepts EConfigBehavior which describes how we want the source control provider to deal with its settings with regards to the ini file. - Note that EConfigBehavior is not a bitfield as we do not wish to support only writing to the ini file, there is no point if it cannot be read from. - When the source control provider is creatred we pass on the into from EConfigBehavior to the FPerforceSourceControlSettings to enable/disable saving and loading. [CL 22163769 by paul chipchase in ue5-main branch]
2022-09-23 20:05:59 -04:00
*
* Perforce Setup
* The backend will attempt to use the current global environment settings for perforce to determine
* the P4PORT and P4USER values. If you wish to set them via an ini file then they can be done per
* user by adding the following to Saved\Config\<platform>Editor\SourceControlSettings.ini
*
* -----
* [PerforceSourceControl.VirtualizationSettings]
* Port=<server address>
* UserName=<username>
* -----
* Note that the backend will read from these ini file settings but will not write to them.
*/
class FSourceControlBackend final : public IVirtualizationBackend
{
public:
explicit FSourceControlBackend(FStringView ProjectName, FStringView ConfigName, FStringView InDebugName);
virtual ~FSourceControlBackend() = default;
private:
/* IVirtualizationBackend implementation */
virtual bool Initialize(const FString& ConfigEntry) override;
Add a number of ways for the VA backend connections to be changed to lazy initialize on first use. #rb Devin.Doucette #jira UE-161599 #rnx #preflight 6303c8d65a5d4e4624e7bf52 - There are some use cases that require the VA system to be initialized and configured correctly but would prefer that the backend connections only run if absolutely needed (usually when a payload is pulled or pushed for the first time), this change provides four different ways of doing this: -- Setting [Core.VirtualizationModule]LazyInitConnections=true in the Engine ini file -- Setting the define 'UE_VIRTUALIZATION_CONNECTION_LAZY_INIT' to 1 in a programs .target.cs -- Running with the commandline option -VA-LazyInitConnections -- Setting the cvar 'VA.LazyInitConnections' to 1 (only works if it is set before the VA system is initialized, changing it mid editor via the console does nothing) --- Note that after the config file, each setting there only opts into lazy initializing the connections, setting the cvar to 0 for example will not prevent the cmdline from opting in etc. - In the future we will allow the connection code to run async, so the latency can be hidden behind the editor loading, but for the current use case we are taking the minimal approach. -- This means we only support the backend being in 3 states. No connection has been made yet, the connection is broken and the connection is working. -- To keep things simple we only record if we have attempted to connect the backends or not. We don't check individual backends nor do we try to reconnect failed ones etc. This is all scheduled for a future work item. - If the connections are not initialized when the VA system is, we wait until the first time someone calls one of the virtualization methods that will actually use a connection: Push/Pull/Query -- We try connecting all of the backends at once, even if they won't be used in the call to keep things simple. - Only the source control backend makes use of the connection system. The horde storage (http) backend could take advantage too, but it is currently unused and most likely going to just be deleted so there seemed little point updating it. - If we try to run an operation on an unconnected backend we only log to verbose. This is to maintain existing behaviour where a failed backend would not be mounted at all. This logging will likely be revisited in a future work item. [CL 21511855 by paul chipchase in ue5-main branch]
2022-08-23 13:01:15 -04:00
virtual EConnectionStatus OnConnect() override;
Packages submitted from the editor together will now virtualize their payloads in a single batch rather than one at a time. #rb PJ.Kack #jira UE-136126 #rnx #preflight ### VirtualizationSystem - Added a new overload for Push to VirtualizationSystem that takes an array of FPushRequest, which is a new structure representing a single payload request. - Filtering by package name is currently disabled, this is because the API has been forced into changing and passing the package name in via a FString rather than FPackagePath which means we would need to be more careful. This will be done in a future submit. - The backend interface has been extended to also have a batch version of PushData, by default this will attempt to submit each request one at a time so payloads don't have to try and implement a batched version if there is no need. - The context being passed with a payload when being pushed has been changed from FPackagePath to FString due to include order issues, as the FPackagePath lives in CoreUObject and the API for virtualization lives in Core. Additionally in the future the payloads might not be owned by a package (there is nothing specifically enforcing this) so the context being a string makes more sense. - NOTE: Due to the context change we currently no longer support the filtering feature, which allows for payloads belonging to packages under specific directories to be excluded from virtualization. This is something that will be solved in a future submit. ### SourceControlBackend - Now that we can submit multiple payloads in the same submit, the CL description has been changed slightly. We will now print a list of payload identifiers -> the package trying to submit that payload. This will only tell the users which package originally caused the payload to submit. If a user submits a new package at a later date that contains the same payload we will not be updating the description. ### PackageSubmissionChecks - Converted the submission process to use the new batch push operation in VirtualizationSystem. -- This means that we do a single push and then have to update the package trailers to convert the now pushed payloads from local to virtualized. - Added new define UE_PRECHECK_PAYLOAD_STATUS that makes it easy to toggle off the checks to see which payloads need to be submitted to the persistent backend. This is useful to test if it actually helps speed up the overall operations or if it is faster to just perform the batch push operations on all payloads and check the return values. -- The hope is that over time the submission processes will become fast enough that we can remove the precheck. - Fixed up logging to not always assume more than one package or payload. ### General Notes - Errors and logging is now a bit more vague as we often not just report that X payloads failed etc rather than specific payload identifiers. This probably doesn't affect the user too much since those identifiers as fairly meaningless to them anyway. - The source control submission could be further optimized by first checking the status of the files in thge depot and only then creating/switching workspace etc. - As currently written, we need to load all of the payloads into memory, then the backends will do what they need (in the case of source control this results in the payloads being written to disk then submitted) which could create quite a large memory spike when submitting a large number of packages. -- One solution would be to change the batch push API to take a "payload provider" interface and have the payloads requested as needed rather than passing in the FCompressedBuffer directly. This would let us immediately write the payload to disk for submission then discard it from memory, preventing larger spikes. Although it could cause overhead if there are multiple backends being submitted to. Internally we are unlikely to have more than one backend per storage solution so maybe we should just make it a config option? #ROBOMERGE-AUTHOR: paul.chipchase #ROBOMERGE-SOURCE: CL 18403735 in //UE5/Release-5.0/... via CL 18403737 #ROBOMERGE-BOT: STARSHIP (Release-Engine-Staging -> Release-Engine-Test) (v896-18170469) [CL 18403738 by paul chipchase in ue5-release-engine-test branch]
2021-12-08 02:19:42 -05:00
virtual bool PushData(TArrayView<FPushRequest> Requests) override;
virtual bool PullData(TArrayView<FPullRequest> Requests) override;
virtual bool DoesPayloadExist(const FIoHash& Id) override;
virtual bool DoPayloadsExist(TArrayView<const FIoHash> PayloadIds, TArray<bool>& OutResults) override;
private:
bool TryApplySettingsFromConfigFiles(const FString& ConfigEntry);
void CreateDepotPath(const FIoHash& PayloadId, FStringBuilderBase& OutPath);
Improved the code logic for where we submit virtualized payloads from and added some additional options. #rb PJ.Kack #jira UE-142926 #preflight 621e1f177f2803279b575764 - Now when payloads are submitted, we will submit them from within the project's saved directory (by default) this now works because we write a .p4ignore file to the submission directory which will override any additional ignore file higher up in the directory structure. -- A new utility function ::CreateSubmissionSessionDirectory was added to make sure that the directory we are submitting from has a p4ignore file. It is added in it's own scope as it is assumed that additional functionality will be added here later. - If a user wishes to choose a different location to submit from, they can override the environment variable "UE-VirtualizationWorkingDir" to provide a different location. This might be useful if the user does not have a huge amount of spare space on the disk that the project is running from. - There is also an optional entry to the ini file set up 'SubmitFromTempDir' (false by default) which when set to true will cause the system to attempt to submit the payload files from the machines temp directory instead. -- There isn't an easy way for users to override this locally, which reduces the usefulness of the option. This might be worth improving in the future although that time would be better spent removing the need for the directory in the first place. - We now try to find/create the root directory to submit payloads from when the backend is created. Failure at this point is not expected and will prevent the backend from working and so is considered an error. - Added more logging to track the session guid when submitting and to be clear about where the files are being submitted from. [CL 19197367 by paul chipchase in ue5-main branch]
2022-03-01 09:05:41 -05:00
bool FindSubmissionWorkingDir(const FString& ConfigEntry);
Give improved error messages to the user if the source control asset virtualization backend fails to connect. #rb PJ.Kack #jira UE-136612 #rnx #preflight 61e589b7904123989a1817cc - If a perforce connection issue is encountered when starting up the editor we will now print an error to the message log and then on the first tick of the editor display a notification to get the users attention. It will no longer result in a fatal error. - Add a new category "Asset Virtualization" to the message log so that we can start to improve the feedback we give to end users rather than only reporting problems via UE_LOG. This also introduces a new localization text name space. -- I will need to go over a lot of the virtualization modules error handling and move it to use the message log instead. - When the source control backend first starts up we now specifically check if the connection works and if not try to give the user feedback on how to fix it. -- Ideally we'd provide a login dialog for the user to fix the problem in place but due to how early in the start up process we need to be able to access the virtualization backends this is quite tricky. - In the future we will build the concept of a backends connection into a formalized concept in the system along with better error handling. At this point FSourceControlBackend::OnConnectionError should be moved to general use for all backends. this will allow us to provide much better status info to the user. #ROBOMERGE-AUTHOR: paul.chipchase #ROBOMERGE-SOURCE: CL 18637036 in //UE5/Release-5.0/... via CL 18637043 via CL 18637054 #ROBOMERGE-BOT: UE5 (Release-Engine-Test -> Main) (v899-18417669) [CL 18637614 by paul chipchase in ue5-main branch]
2022-01-18 04:50:38 -05:00
/** Will display a FMessage notification to the user on the next valid engine tick to try and keep them aware of connection failures */
void OnConnectionError(FText Message);
/** A source control connection owned by the backend*/
TUniquePtr<ISourceControlProvider> SCCProvider;
/** The name of the current project */
FString ProjectName;
/** The root where the virtualized payloads are stored in source control */
FString DepotRoot;
/** Address of the server to connect to */
FString ServerAddress;
/** The stream containing the DepotRoot where the virtualized payloads are stored in source control */
FString ClientStream;
Improved the code logic for where we submit virtualized payloads from and added some additional options. #rb PJ.Kack #jira UE-142926 #preflight 621e1f177f2803279b575764 - Now when payloads are submitted, we will submit them from within the project's saved directory (by default) this now works because we write a .p4ignore file to the submission directory which will override any additional ignore file higher up in the directory structure. -- A new utility function ::CreateSubmissionSessionDirectory was added to make sure that the directory we are submitting from has a p4ignore file. It is added in it's own scope as it is assumed that additional functionality will be added here later. - If a user wishes to choose a different location to submit from, they can override the environment variable "UE-VirtualizationWorkingDir" to provide a different location. This might be useful if the user does not have a huge amount of spare space on the disk that the project is running from. - There is also an optional entry to the ini file set up 'SubmitFromTempDir' (false by default) which when set to true will cause the system to attempt to submit the payload files from the machines temp directory instead. -- There isn't an easy way for users to override this locally, which reduces the usefulness of the option. This might be worth improving in the future although that time would be better spent removing the need for the directory in the first place. - We now try to find/create the root directory to submit payloads from when the backend is created. Failure at this point is not expected and will prevent the backend from working and so is considered an error. - Added more logging to track the session guid when submitting and to be clear about where the files are being submitted from. [CL 19197367 by paul chipchase in ue5-main branch]
2022-03-01 09:05:41 -05:00
/** The root directory from which payloads are submitted. */
FString SubmissionRootDir;
/** The name to use for the p4 ignore file */
FString IgnoreFileName = TEXT(".p4ignore.txt");
/** Should we try to make the temp client partitioned or not? */
bool bUsePartitionedClient = true;
/** When true, the backend will not raise a pop up notification on connection error */
bool bSuppressNotifications = false;
/** The maximum number of files to send in a single source control operation */
int32 MaxBatchCount = 100;
/** A counted semaphore that will limit the number of concurrent connections that we can make */
TUniquePtr<UE::Virtualization::FSemaphore> ConcurrentConnectionLimit;
/** The number of times to retry pulling a payload from the depot */
int32 RetryCount = 2;
/** The length of time (in milliseconds) to wait after each pull attempt before retrying. */
int32 RetryWaitTimeMS = 100;
};
} // namespace UE::Virtualization