#rb Sebastian.Nordgren, Ryan.Hummer
#rnx
#preflight 636a63c063037c1026488d19
- We search the changelist description for '#preflight ???' and then open the appropriate page.
- If no tag is found we will display a message to the user via a modal dialog so that they are aware that no page will be opened.
- Refactored PreflightCommand.OpenUrl to be a public static method to avoid copy and pasting code.
- Refactored PreflightCommand.GetUrl to move the extraction of the Horde server address to a public static method to improve code re-use.
- The command will be added to P4 so that it can be used on pending and submitted changelists.
[CL 23050223 by paul chipchase in ue5-main branch]
#rb trivial
- The bat files can be used to uninstall the version of P4VUtils provided by UGS (to provide a blank slate for development) and then re-install that version when done.
[CL 23009814 by paul chipchase in ue5-main branch]
#rb Sebastian.Nordgren
#jira UE-155978
#preflight 63690858d0174259ccbd601c
- When this tool was written the p4 c# api did not return the submitted changelist number, so as a quick work around we just logged the original changelist number.
- Since the C# api was fixed and now returns the submitted changelist value we can log it.
- Changed the comments to show why we can have multiple records back.
[CL 23009761 by paul chipchase in ue5-main branch]
#rb trivial
#rnx
#preflight 6368efb063037c102686e1ea
- Prefixed all error logs with "Error: " as the p4v terminal does not support text colours so there was no way to tell info from an error.
- Reworded some logging info and added a few more linebreak to improve readability.
[CL 23009315 by paul chipchase in ue5-main branch]
#rb Sebastian.Nordgren
#jira UE-168878
#rnx
#preflight 6368dea2d0174259cc4bdfb1
- Previously we were checking the version of the tool (if found) and assuming that a promoted build meant a precompiled binary. Recent changed to our build farm means that this assumption no longer works and was preventing people who did not have source code synced from running the tool.
- The previous logic was to check if the editor was a PCB and if it was not then compile the code locally. So if a user downloaded PCB we would use them, up until they recompiled the editor locally at which point we'd change to compiling UnrealVirtualizationTool as well, which was an attempt to keep things in sync. However once we stopped detecting PCB properly, every editor was considered "locally built" meaning we had to build the tool and this would prevent users without source code (who could not build) from continuing.
- As a short term fix the logic has been changed. We now check to see if the UBT project can be found. If it can we assume the user has source code in which case we just build the tool. If we do not find the project we assume no source code and the user must be using PCB, so we try to use that.
- This does mean that a user with source code could get a mismatch in future, using the PCB editor with a locally built UnrealVirtualizationTool (that might have changes compared to the editor) but that case should be less common and less of a problem than our current issues.
- This logic change can be reverted once a method is deployed that will allow us to more reliably tell the difference between PCB exes and locally built.
[CL 23009202 by paul chipchase in ue5-main branch]
Renamed UE Helpers to UE Toolbox
Moved backout tool to UE Toolbox
Moved 'find last edit' to 'Root Helpers' (from UE Helpers)
#jira UE-159399
#rnx
#preflight n/a
#rb Marc.Audy, Ben.Marsh
[CL 21092009 by aurel cordonnier in ue5-main branch]
- will now report multiple safety concerns if there are > 1
- message box body is now limited to 2048 characters to avoid issue where you can't even see the buttons (all errors are still logged to the console window which has a scroll bar)
#rb Marc.Audy, Ben.Marsh
#preflight n/a
#jira none
#rnx
[CL 20760560 by aurel cordonnier in ue5-main branch]
- check if the CL desc indicates that it was a robomerge or a cherry pick (ushell or p4v)
- check that the backout is of an edit operation (edit/add/delete) and not an integration
- check that the CL doesn't contain objeect or engine version files
- throw a dialogue if any of the above checks considers the backout 'unsafe'
Fixed revert exception when the backout fails due to files being checked out (also added warning similar to P4V's undo operation)
#preflight n/a
#rnx
#rb Marc.Audy, Ben.Marsh
[CL 20581794 by aurel cordonnier in ue5-main branch]
#rb Sebastian.Nordgren
#rnx
#preflight 62985fe89907cbadbaa25855
- This is a follow on fix from 20451429, although that solved the problem of duplicate registered commands due to differing DotNet locations it did not solve a problem introduced in 20248689 caused by quoting the command argument.
- If the path in the command element does get quoted due to containing a space in the file path then FileReference will fail to parse it as RemoveCustomToolsFromNode intended and the comparison between the Command element and the DotNet location would always fail.
-- This meant that a newly published version of the tool would replace the old commands, but when published a second time would start to register duplicate commands.
- The simple solution is to try and strip the quotes (if any) before creating the FileReference for comparison.
[CL 20466696 by paul chipchase in ue5-main branch]
#rb Josh.Adams
#rnx
#preflight 62975f7c101592b805fa7cb9
- When UGS invokes the tool to be installed, it will call 'P4VUtils.exe install' which meant that getting the process path as the dotnet path would return the exe
- However previous versions of the tool were creating a path to dotnet.exe to use as the dotnet path
- When removing the old commands before installing the new ones, one of the filters is to check the dotnet path of the command and make sure that it matches the current one
- So if the older version was using a path to dotnet.exe and the newer version, the p4vutils.exe, they won't match and the old commands won't be removed, so when the new ones are added we end up with duplicates.
- For now the easiest fix is to go back to the logic before change 20248689, so on windows we make sure that we find dotnet.exe so it will match.
[CL 20451429 by paul chipchase in ue5-main branch]
#rb Sebastian.Nordgren
#rnx
#jira UE-152958
#preflight 629717b72c618ddc669143d7
- Instead of just building the UnrealVirtualizationTool we will now check to see if there is a precompiled version we can use.
-- If the user has rebuilt the editor locally, then we will ignore any precompiled version of UnrealVirtualizationTool and rebuild that aswell incase there are code changes that it needs to pick up.
- To tell if an exe is locally built or a precompiled binary we check for a .version OR .target file (this can vary depending how a program is set up) then look for the JSON property 'IsPromotedBuild ' which when none zero means that the binary is probably prebuilt.
-- This isn't very robust and I am not happy with it, but we don't seem to have an official way to determine a precompiled binary. When we do get an offical way to do it I will update the command.
[CL 20448604 by paul chipchase in ue5-main branch]
#rb Sebastian.Nordgren
#jira UE-154011
#rnx
#preflight 6294a6eb380652524ebcc4a7
- If we use uppercase %C in P4V to pass the changelist number then we will get a list of all changelists that the user has selected rather than launching the command once per changelist which is what happens when the lower case %c is used
-- Due to the use of UBT, we can run into problems if the user tries to submit multiple changelists and they are processed in different processes. Even if we fixed the command to only run UBT one process at a time, running many versions of the submit tool will create many more perforce connections which we'd like to avoid, so having all of the changelists run through one instance is still prefered.
- Processing a changelist has been moved to a new method, ::ProcessChangelist which is pretty much the same code as we had in ::Execute.
-- Rather than connecting to perforce for each changelist, this code has been kept in ::Execute and is only run once, the connection is then passed to ::ProcessChangelist.
- Logging has been improved to show when the tool is exiting, either from failure or success. The p4v terminal does not do a good job informating the user when the process has finished running so hopefully this will help.
- A small extension to ILogger has been added, ::NewLine which writes an empty line to the logger.
- This was the simplest way to add support to multiple changelists. We process each one by itself until we run out of changelists or we reach an error. However it is likely that packages in multiple changelists would be in the same project or at least use the same engine installation, so we could remove some overhead by parsing all changelists, gathering the packages, virtualizating those packages then submitting the changelists afterwards.
-- This would be a great approach for the average user as they will likely be submitting relatively small changelists (< 100 files) but would be a terrible approach if the entire project was being virtualized where the total number of packages being submitting could be in the 100k-million range. So we'd probably want a "process changelists separatly" mode even if we did make the optimized version.
-- Looking into adding a combined changelist mode will be added as an optimization task.
- Added a new preprocessor define 'UE_DEBUG_DISABLE_SUBMITS' that when enabled will cause the command to only pretend to submit the target changelist(s) this is intended for use in development to avoid submitting changelists over and over when testing the non-submission portion of the command.
-- Note that it is defined inside of a DEBUG check, so even if it is accidently submitted enabled, it will not be published.
[CL 20429873 by paul chipchase in ue5-main branch]
#rb trivial
#rnx
#preflight 628ccca9fc217779d4361cb5
- The native code changes we are trying to match from CL 20346906, fix a problem when parsing a package path containing more than one content directory.
- The method now takes an ILogger so that we can record problems found.
- Even though we don't use the .uplugin file, we now match the native code and look for it first, rather than looking for the /plugins/ directory immediately. This should reduce any differences between the two code paths.
[CL 20346914 by paul chipchase in ue5-main branch]
#rb Sebastian.Nordgren
#rnx
#preflight 628c85f58673efbf3c0a5e3f
- Added checks when parsing xml to make sure that expected nodes/lists were found and are not null.
- Response was assigned as null, but nothing was checking for this. The initial value has been changed to an empty string which wioll invoke the user cancelling the operation as the default behaviour.
- StreamReader.ReadToEnd is a blocking call in an async method. Replaced with await StreamReader.ReadToEndAsync.
[CL 20346208 by paul chipchase in ue5-main branch]
- Split up the binaries between platform since there are #if's due to WinForms
#rb trivial
#preflight skip
[CL 20247967 by Josh Adams in ue5-main branch]
- Will compile on Mac and Linux now
- Mac replaced the WinForms functionality with AppleScript
- Linux will compile be have reduced functionality
- Fixed up paths for p4v settings and dotnet location
- Added binaries and installer scripts for all 3 platforms - won't need UGS to install, will copy to user-library location (may need some adustment on Linux, will address after)
#rb will.damon
#preflight skip
[CL 20244727 by Josh Adams in ue5-main branch]
#rb Sebastian.Nordgren
#rnx
#jira UE-151464
#preflight 627a4c60fc07e0a9b4eefda9
### No files
- When submitting a change list with no workspace files (either empty changelist or only shelved files) our internal C# api does not return any errors.
- To get around this for now ::FindPackagesInChangelist can be changed to return null if we detect that there are no files to submit.
- I am following up with the original author to try and find out if the submit behavior in our API is intended or not.
### Shelved files
- Attempting to submit a valid changelist that has shelved files will eventually fail when we try to finally submit the changelist.
- This means that the tool will check all of the packages for virtualization first, before eventually failing on the submit.
- Most users will alt tab out of p4v during the submit and we cannot do anything fancy with the error reporting (like make the task bar icon flash etc) so might not notice that the submit failed for some time.
- So it makes sense for us to check for shelved files, before we kick off the virtualization process and if the changelist does have shelved files we can error out and the user should see it before they alt tab away.
[CL 20120836 by paul chipchase in ue5-main branch]
#rb trivial
#rnx
#preflight 627a14806a20515edc79c799
- Only display the p4 submit error messages, doo not include the perforce generic code as it can be confusing to the end user.
- If a submit fails, print a line to the log once the virtualization tags have been removed from the original changelist description. Previously the last message the user would see ended in "..." which implied that the process was still running.
[CL 20119794 by paul chipchase in ue5-main branch]
