Almost all game development project teams hope to hand over repetitive operations such as packaging, uploading, and testing to the automated assembly line for processing. When performing such automated tasks, if there are project changes, Unity version differences, and package changes, etc., The project team needs to reconfigure relevant parameters to ensure the normal operation of the pipeline.
If the parameters can be changed infrequently, and the tasks can be flexibly adapted to different situations with the same configuration, the efficiency of pipeline operation will be greatly improved, and it can truly run automatically without intervention. Regular expressions can play such a role. It is a very common processing mode in string operations. It can quickly filter out the results that meet the requirements through some keywords or specific style specifications.
UWA Pipeline already supports regular expressions in the configuration of some functions, which can realize the adaptation of a class of different parameters. Next, we will give examples of several application scenarios for your reference when configuring parameters in UWA Pipeline.
1. Upload to package management - apk/ipa package path
Many teams will name the installation package according to the type of package body (such as Mono/IL2CPP), iteration version number (such as v3.2.010), or time and date (such as 20230101), and put the corresponding iconic characters The string is used as a part of the name for easy identification and management.
Through the "upload to package management" step, the installation package is automatically uploaded, which is convenient for everyone to perform automatic installation and testing. However, due to the upload function, you need to fill in the absolute path of the installation package, specifically to the ".apk/.aab/.ipa" file, and the name of the installation package changes every time the package is released, so the relevant configuration must be modified accordingly. Ensure the normal operation of the pipeline.
In this case, using regular expressions in the configuration of the apk/ipa package path can achieve matching of certain keywords or specific formats, eliminating the need for frequent manual modification, allowing the execution of pipeline tasks to achieve real "automation" ".
1. Keyword matching
For example, the name of the project package will always contain the keyword "IL2CPP", and there may be other uncertain letters and numbers before and after, such as "C:\Users\vip\Downloads\test \packIL2CPPempty.apk".
UWA Pipeline supports the form of "path + regular" in the path configuration, so when we fill in the apk package path, it can be written as: C:\Users\
vip\Downloads\test\ ^[a-z0-9A-Z]* I {1} L {1} 2 {1} C {1} P {1} P {1}[a-z0-9A-Z]* \.apk $
Pipeline will use the start character "^" and the end character "$" as the identification of the content of the regular expression: the non-regular part is still compared with the path string; the regular part is matched with the syntax of the regular expression.
So we can write the original path as:
C:\Users\vip\Downloads\test^.*IL2CPP.*\.apk$
2. Matching of specific formats
For example, we added the date of the current day in the naming of the project when it was outsourced for distinction.
For example, "C:\Users\vip\Downloads\test\pack20230101empty.apk", the naming feature of the installation package is the date format in the style of " xxxx xx xx ".
At this time, "path + regular expression" can be written as: C:\Users\vip\Downloads\test^.* \d {4}\d{1,2}\d{1,2} .*\.apk$
Pay attention to the use of "\d{n}" here . This combination realizes the matching of a string of unknown numbers with a length of n, and can flexibly match fixed digital formats such as dates and version numbers.
2. Other applications of regular expressions
In addition to the "upload to package management" step, there are many functions in UWA Pipeline that can use regular expressions in related configurations, and match "keywords" and "specific formats" to adapt to changes in the content of most parameters. , to reduce the input of manpower modification. The main application scenarios are:
1. The path configuration of the installation package in the step of " Testing on Real Devices ".
2. In the " local resource detection " step, the path configuration of UnityPath and projectPath.
What needs to be reminded here is: when configuring UnityPath, the path should be accurate to Unity.exe; when configuring projectPath, it should be accurate to the directory where the project project is located, not a specific resource folder under it.
3. In the " AssetBundle detection " step, scan the path configuration of the directory.
Different from other path configurations, the configuration of the "AssetBundle Detection" scanning path can not be limited to the project directory level, but can be assigned to any desired folder.
4. Set UnityPath, Unity project path, Android package path, and iOS package path in the " Build Report " step.
The points to note are basically the same as above: "UnityPath" must be accurate to Unity.exe; "Unity project path" must be accurate to the directory where the project project is located; "Android package path" must be accurate to .apk; "iOS package path" must be accurate to . ipa.
3. Path configuration in the Local Resource Detection Setting interface
In the recent update of local resource detection version 3.1.0, regular expressions have been supported (see "Local Resource Detection｜Single Rule Multi-Threshold Setting Function Online" for details ), and you can use the same name for a class under specified rules characteristic folders or resources to scan.
When configuring, you can choose to use path strings for comparison, or use regular expressions for matching.
1. In Unity's local resource detection, the resource path is represented by a relative path beginning with "Assets", and the path matching function also matches this relative path.
2. In order to distinguish it from escape symbols, use "/" for all path separators. To match delimiters in a regular expression, " [/] " should be used.
3. If regular expressions are used for matching, the regular expression matching strategy is "partial matching", that is, as long as a part of the path of the resource is successfully matched by the regular expression, the resource is considered to be successfully matched and will be included in the resources to be detected list. If you want to do a complete match on the path of the resource, you can use the symbols " ^ " and " $ " to indicate the beginning and end of the path.
There are two main usages of regular expressions in local resource detection:
1. Match folders with a certain type of naming characteristics
. For example, if we want to scan resources under multiple folders with "Texture" in the name, then use the combination of ".", "*", etc., The regular expression can be written as: Assets[/].*Texture.*[/], so as to delineate the detection scope of the rule.
It should be noted here that there may be specific resources named "Texture" in the project, such as Assets\ABC001\Texture002.jpg. If your regular expressions are not written rigorously, then these resources that are not within the scope of scanning are likely to appear in the scanning results.
So we should pay attention to exclude the interference of these "same name" resources. Here is a relatively simple principle: there must be a slash on the right side of the folder; there must be no slash on the right side of the resource.
Because the final scan result is a resource, the form must be "Assets/folder 1 layer/folder 2 layer/folder N layer/resource. format", so when we want to match a folder, in the regular expression Add a fixed "[/]" at the end, so that it will not be interfered by "same name" resources.
2. Match the resource files with a certain type of naming characteristics
. For example, if we want to scan the texture resources of the project, and name a type of texture with "001", combined with our previous understanding, the regular expression can be written as: Assets [/].*001[^/]*\.jpg
Similarly, when we write regular expressions, we should pay attention to the interference of those "same name" folders on the detection results.
Based on "There must be a slash on the right side of the folder; there must be no slash on the right side of the resource" , we need to ensure that the existence of "slash" is excluded from the results filtered by the regular expression. So we can write " [^/]* ".
The use of regular expressions in UWA Pipeline and various products does not seem to be eye-catching, but as long as it can be used reasonably, you can avoid a lot of tedious settings and modification operations, reduce interruption and interference to pipeline tasks, and make "automation "The execution efficiency has been improved to a higher level.
There are many similar usage tips in UWA Pipeline, which can play many unexpected roles. We will give more references in the future, and everyone is welcome to actively share.
Want to experience UWA Pipeline in action? Please click "Free Trial｜Full Experience of UWA Performance Guarantee System" , and the 15-day Pipeline full-service trial is just around the corner!