Code pre-submission verification method and device, equipment and storage medium

Abstract

The application discloses a code pre-commit verification method and device, equipment and a storage medium. When a code commit operation performed by a developer is detected, a pre-constructed hook script is activated to verify and intercept the code commit operation, and context information corresponding to the code commit operation is triggered. The changed file is determined from the context information. The change type of the changed file is analyzed, and the build range is determined according to the change type. The build range is incrementally built to determine the compilation result. If the compilation result is a compilation failure, the code commit operation is blocked. If the compilation result is successful, the code commit operation is continued. The application determines the changed file to build according to the actual influence range, solves the efficiency problem of long time consumption of full build, and then determines whether to commit according to the success or failure of the compilation result.

Description

Technical Field

[0001] This application relates to the field of code submission verification technology, specifically to a code submission verification method, apparatus, device, and storage medium. Background Technology

[0002] In the software development process, after developers complete writing or modifying code, they usually need to commit the changes to the code repository. To ensure the quality of the committed code and prevent code with compilation errors from entering the shared code repository and affecting other developers, a common practice is to perform compilation verification before code submission. The existing method of pre-submission compilation verification usually involves performing a full build and compilation of the project when the developer performs the code submission operation.

[0003] However, as software projects continue to grow in size, the number of code files becomes enormous, and module dependencies become complex. Full builds often require a lot of time and computing resources, making the existing verification method very inefficient. Summary of the Invention

[0004] In view of this, this application provides a method, apparatus, device and storage medium for pre-commit code verification, which solves the problem that due to the large number of code files and complex module dependencies, full builds often require a lot of time and computing resources, and existing verification methods are very inefficient.

[0005] To achieve the above objectives, the following solution is proposed: Firstly, a method for verifying code before submission includes: When a developer is detected performing a code commit operation, a pre-built hook script is activated so that the hook script can verify and intercept the code commit operation and trigger the capture of context information corresponding to the code commit operation. The changed file is determined from the context information; Analyze the change types of the modified files and determine the build scope based on the change types; Incremental build is performed on the constructed scope to determine the compilation result; If the compilation result is a compilation failure, the code submission operation is blocked; if the compilation result is a success, the code submission operation continues.

[0006] Preferably, activating the pre-built hook script includes: Obtain the names of the pre-built hook scripts and the names of each original hook script in the local script directory; Determine whether an original hook script with the same name as the pre-built hook script exists in the local script directory; If so, the execution logic of the pre-built hook script is added to the original hook script with the same name, and the execution order is set as follows: first execute the execution logic of the original hook script, and then execute the logic of the pre-built hook script.

[0007] Preferably, determining the changed file from the context information includes: Extract the file list and commit message from the context information; The submission message is segmented to obtain submission intent keywords; For each file in the file list, extract the file name, file path, and specific changes made to that file; Calculate the relevance score between the file and the submitted intent keywords based on the file name, file path, and specific changes; Files with a relevance score higher than the preset relevance threshold are considered as files that have been changed.

[0008] Preferably, determining the build scope based on the change type includes: If the change type is deletion, then the file that has been changed is treated as a deleted file, and the file identifier of the deleted file is determined. The file identifier is used as the query key to query the pre-built module dependency graph to determine whether there is a dependent module in the module dependency graph that declares a dependency relationship with the deleted file. If no dependent modules that declare a dependency on the deleted file are found, the deleted file will be used as the build scope.

[0009] Preferably, determining the build scope based on the change type includes: If the change type is modification type, then the file that has been changed is treated as the modified file, and the abstract syntax tree of the modified file before modification and the abstract syntax tree after modification are parsed. Match these two abstract syntax trees to locate and modify the corresponding code nodes; Determine the scope hierarchy of the code node in the modified abstract syntax tree; the scope hierarchy includes the exported interface hierarchy and the internal implementation hierarchy; If the scope level of the code node is the export interface level, then the file identifier of the modified file is determined, and the file identifier is used as the query key to query in the pre-built module dependency graph to determine the build scope; If the scope level of the code node is the internal implementation level, then only the modified file will be determined as the build scope.

[0010] Preferably, determining the build scope based on the change type includes: If the change type is a new type, then the changed file is treated as a new file, the file identifier of the new file is obtained, and the abstract syntax tree of the new file is parsed to extract each declaration node modified by the preset keyword in the abstract syntax tree. Obtain the export identifiers of each of the declared nodes to form a set of export interfaces; Iterate through all the other modified files except the newly added file, and determine whether the import declaration of any other modified file references the file identifier, and / or whether the identifier referenced in the import declaration of any other modified file matches any export identifier in the export interface set. If so, both the changed files and the newly added files will be included in the build scope.

[0011] Preferably, after determining the document that has been changed, the method further includes: The initial set of changed files consists of all the files that have undergone changes. Iterate through each changed file in the initial set of changed files and determine whether the file type of the changed file belongs to any of the preset build configuration file types. The build configuration file types include build tool configuration files, compilation option files, dependency declaration files, and environment variable configuration files. If so, a global configuration change marker is generated and appended to the initial set of change files to obtain the target set of change files.

[0012] Secondly, a verification device for code submission includes: The context information capture module is used to activate a pre-built hook script when a developer is detected to be performing a code submission operation. The hook script then verifies and intercepts the code submission operation and triggers the capture of context information corresponding to the code submission operation. The changed file determination module is used to determine the changed file from the context information; A scope determination module is used to analyze the change type of the modified file and determine the scope of construction based on the change type; The compilation result determination module is used to perform incremental builds on the constructed scope to determine the compilation result. The judgment module is used to block the code submission operation if the compilation result is a compilation failure, and to continue executing the code submission operation if the compilation result is a success.

[0013] Thirdly, a verification device for code submission, including a memory and a processor; The memory is used to store programs; The processor is configured to execute the program to implement the steps of the pre-submission verification method as described in any of the first aspects.

[0014] Fourthly, a storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the code submission verification method as described in any of the first aspects.

[0015] As can be seen from the above technical solution, when this application detects a developer performing a code submission operation, it activates a pre-built hook script to verify and intercept the code submission operation, and triggers the capture of context information corresponding to the code submission operation; it determines the changed file from the context information; it analyzes the change type of the changed file and determines the build scope based on the change type; it performs incremental build on the built scope to determine the compilation result; if the compilation result is a compilation failure, it blocks the code submission operation; if the compilation result is a success, it continues to execute the code submission operation. This application intercepts code submissions from developers, captures context information, and identifies the changed files. This focuses attention on the altered parts, allowing incremental builds to be performed based on the actual impact of each changed file. This excludes unchanged parts that don't need recompilation and covers affected dependency files that weren't modified. Compilation is then performed only on the minimum necessary parts, shifting the focus from full builds to incremental builds, thus solving the efficiency problem of long full build times. Subsequent commits can then be determined based on the success or failure of the compilation results. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0017] Figure 1 An optional flowchart of a code submission verification method provided in an embodiment of this application; Figure 2 A schematic diagram of a code submission verification device provided in this application embodiment; Figure 3This is a schematic diagram of the structure of a verification device before code submission, provided as an embodiment of this application. Detailed Implementation

[0018] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0019] This invention can be used in a wide variety of general-purpose or special-purpose computing environments or configurations. For example: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor devices, distributed computing environments including any of the above devices, etc.

[0020] This invention provides a method for verifying code before submission. This method can be applied to various computer terminals or smart terminals, and its execution entity can be the processor or server of the computer terminal or smart terminal. The method flowchart is shown below. Figure 1 As shown, it specifically includes: S1: When a developer is detected to be performing a code submission operation, a pre-built hook script is activated so that the hook script can verify and intercept the code submission operation and trigger the capture of context information corresponding to the code submission operation.

[0021] When a developer is detected committing code, a pre-built hook script is activated. This script verifies and intercepts the code commit, and triggers the capture of context information corresponding to the commit.

[0022] The reason why full builds in existing technologies are slow is that they compile the entire project with every commit, regardless of how many files were changed. To make the build target only the changed parts, it's necessary to clearly define which files were modified. Therefore, this step requires determining the context information corresponding to the code commit operation. This context information includes the staging area file list, commit information, etc. Without this information, it's impossible to determine the boundaries of this commit, and thus impossible to distinguish which files need to be compiled and which don't. Therefore, this step provides the necessary data support for subsequent incremental builds.

[0023] S2: Determine the file that has been changed from the context information.

[0024] Understandably, the context information is raw and unprocessed, thus containing a lot of content unrelated to compilation. This step requires extracting the files that were actually changed in this commit from the context information, forming a clear list of files, and narrowing the verification scope from the entire project to the files involved in this change. In a project with a large number of files, a full build requires traversing all modules in the project and compiling them one by one. However, this step outputs a limited set of changed files. Although the final build scope has not yet been determined, the target has been narrowed from the entire project to the actual change scope, solving the problem of low efficiency of a full build from the source.

[0025] S3: Analyze the change type of the modified file and determine the build scope based on the change type.

[0026] This step addresses the issue of defining the build scope, which is the core step that distinguishes incremental builds from full builds. In practice, different types of changes have different compilation requirements. For example, deleted files do not need to be compiled; only old artifacts need to be cleaned up. Modified files need to be compiled, and if the modification involves an external interface, dependent files need to be recompiled even if they themselves have not been modified; otherwise, runtime issues such as interface mismatches will occur. Newly added files need to be compiled, and if other files reference them, those files also need to be compiled together.

[0027] This step analyzes the impact of each file according to the type of change, and finally determines a build scope. This build scope is controlled within the minimum necessary range, so that no affected files are missed and no irrelevant files are included. The compilation volume is reduced from the full volume to a variable, and the size of the variable depends on the impact of this change, rather than the total size of the project.

[0028] S4: Perform incremental builds on the constructed scope to determine the compilation result.

[0029] In existing full build schemes, the compilation action targets the entire project. However, in this application, the compilation action targets the build scope determined in step S3. Since the build scope is determined based on the impact of the change, and the impact of the change is smaller than the total project size, the compilation time of this application is significantly shortened compared to a full build.

[0030] S5: If the compilation result is a compilation failure, then the code submission operation is blocked; if the compilation result is a success, then the code submission operation continues.

[0031] This step controls whether to allow or block commits based on the compilation results. Compared to the full build approach, the decision-making basis in this step is also the compilation results, but the time spent obtaining these results is shorter. Blocking commits when compilation fails prevents problematic code from entering the repository or database; allowing commits when compilation succeeds eliminates the need for developers to wait for a full build to complete before committing. Therefore, without lowering the threshold for ensuring the quality of submitted code, the time developers spend waiting for verification results is reduced.

[0032] As can be seen from the above technical solution, when this application detects a developer performing a code submission operation, it activates a pre-built hook script to verify and intercept the code submission operation, and triggers the capture of context information corresponding to the code submission operation; it determines the changed file from the context information; it analyzes the change type of the changed file and determines the build scope based on the change type; it performs incremental build on the built scope to determine the compilation result; if the compilation result is a compilation failure, it blocks the code submission operation; if the compilation result is a success, it continues to execute the code submission operation. This application intercepts code submissions from developers, captures context information, and identifies the changed files. This focuses attention on the altered parts, allowing incremental builds to be performed based on the actual impact of each changed file. This excludes unchanged parts that don't need recompilation and covers affected dependency files that weren't modified. Compilation is then performed only on the minimum necessary parts, shifting the focus from full builds to incremental builds, thus solving the efficiency problem of long full build times. Subsequent commits can then be determined based on the success or failure of the compilation results.

[0033] The process of activating a pre-built hook script in the method provided by this invention is described in detail below: Obtain the names of the pre-built hook scripts and the names of each original hook script in the local script directory; Determine whether an original hook script with the same name as the pre-built hook script exists in the local script directory; If so, the execution logic of the pre-built hook script is added to the original hook script with the same name, and the execution order is set as follows: first execute the execution logic of the original hook script, and then execute the logic of the pre-built hook script.

[0034] Specifically, the above process is to handle the possible conflict issues between existing hooks and hooks to be deployed. The installation process can be triggered through npm scripts, and predefined hook scripts (pre-commit, pre-push) are written into the ".git / hooks" directory of the project.

[0035] Adopt a non-overwriting merge strategy: when detecting existing hooks, automatically back up the original script and append the new logic to the execution chain to retain the original functions. The updater can also perform version comparison and pull remote configurations to ensure that the hook scripts are updated synchronously as the project evolves, supporting gray release and rollback mechanisms.

[0036] The process of determining the changed files from the context information in the present application will be described in detail below.

[0037] Extract the file list and commit message from the context information; Perform word segmentation on the commit message to obtain commit intent keywords; For each file in the file list, extract the file name, file path, and specific change content of the file; Calculate the correlation score between the file and the commit intent keywords based on the file name, file path, and specific change content; Take the files with a correlation score higher than the preset correlation threshold as the changed files.

[0038] Specifically, the context information includes two parts: the file list in the staging area and the commit message. The file list in the staging area is the set of all files involved in this commit, and the commit message is the text description of the purpose of this commit by the developer. For example, a natural language text: "Fix the problem of token expiration in the user login module". Word segmentation is to split this text into meaningful word units, such as "fix", "user", "login", "module", "token", "expiration", "problem". After splitting, stop words without actual meaning, such as "of", "the", "in", etc., are removed. The remaining words are the commit intent keywords. This step converts a descriptive text written by the developer into a set of structured keyword tags, and these keywords are used in subsequent steps to measure the association degree of each file with the intent of this commit.

[0039] For each file in the file list, extract information in three dimensions: filename (including extension, e.g., LoginService.js), file path (the complete path of the file in the project directory structure, e.g., src / services / LoginService.js), and changes (the actual lines of code modified in this commit, obtained via git diff, including added and deleted lines). These three dimensions cover the file's identifier (name), organization (path), and content (changes). Each dimension carries different semantic information: the filename typically reflects the file's core functionality, the file path reflects the functional module to which the file belongs, and the changes reflect what was specifically modified in this commit.

[0040] The relevance score is calculated based on the following three factors: the textual match between the file name and the intent keywords, the path match between the file path and the intent keywords, and the frequency and distribution of the intent keywords in the changed content. Specifically: The process of calculating the text matching degree between file name and intent keyword includes: matching the file name with each keyword; if the file name contains the keyword or a variation of the keyword (e.g., Login matches login, login, LoginService), it is considered a match. The more keywords that are matched and the higher the matching accuracy, the higher the score for this dimension.

[0041] The process of calculating the path matching degree between file path and intent keyword includes: matching the directory names at each level of the file path with the keyword. For example, if the intent keyword is "login" and the file path is src / modules / login / components / LoginForm.js, the path contains the directory name "login", which means that the file belongs to the login module in terms of organization and is highly related to the submission intent. The path matching degree reflects the consistency between the module affiliation of the file and the submission intent.

[0042] The calculation process for the frequency and distribution of intent keywords in the changes includes: counting the number of times and positions of intent keywords appearing in the specific changes to the file; the more times they appear, the more the changes revolve around the keyword; keywords appearing in key positions (such as function names, variable names, and newly added lines of code) have a higher weight than those appearing in comments or strings. This dimension directly reflects the degree of correlation between the modification action and the submission intent.

[0043] The relevance score is calculated by weighting and summing text matching, path matching, and frequency of occurrence. The weights for each factor can be set as needed, or each factor can account for one-third. Files with scores above a preset threshold are retained, while those below the threshold are excluded. The threshold filters out incidental changes unrelated to the submission's intent. For example, if a developer fixes the login module but casually modifies a comment or adjusts the indentation of an unrelated configuration file, these changes have a low relevance score to the submission's keywords and will be excluded from the list of changed files.

[0044] The following embodiments provide a detailed explanation of the steps in this application for determining the scope of construction based on the change type.

[0045] This application categorizes change types into three types: deletion, modification, and addition.

[0046] 1) Change type is now deletion type.

[0047] If the change type is deletion, then the file that has been changed is treated as a deleted file, and the file identifier of the deleted file is determined. The file identifier is used as the query key to query the pre-built module dependency graph to determine whether there is a dependent module in the module dependency graph that declares a dependency relationship with the deleted file. If no dependent modules that declare a dependency on the deleted file are found, the deleted file will be used as the build scope.

[0048] Specifically, if at least one dependent module in the module dependency graph declares a dependency on the deleted file, then all the queried dependent modules are traversed to obtain the code location in each dependent module that references the deleted file; a reference error report is generated based on the code location.

[0049] When dealing with the type of deletion, we need to consider: if a file is deleted, are there any other files in the project that reference it? If so, this commit cannot be approved, because deleting a dependent file will cause the project to fail to compile or throw a runtime error.

[0050] Therefore, it's necessary to first determine the file identifier. The file identifier is information that uniquely identifies a file within the project, typically its relative path, such as `src / utils / DateHelper.js`. This file identifier is the key-value pair used for subsequent lookups in the module dependency graph. The module dependency graph is a pre-built data structure that records the dependencies between files in the project. Nodes in the graph represent files, and edges represent import or dependency relationships between files. For example, if file A contains `import { formatDate} from '. / DateHelper'`, there will be an edge in the graph pointing from A to `DateHelper`, indicating that A depends on `DateHelper`. Now that `DateHelper` is to be deleted, the dependency graph is searched using `DateHelper`'s file identifier as the lookup key, finding all nodes that declare a dependency on `DateHelper`—that is, the starting points of all edges pointing to `DateHelper`. These starting points are the dependent modules—their code contains statements referencing `DateHelper`. Once `DateHelper` is deleted, these modules will fail to compile because they cannot find the dependency.

[0051] If a dependent module is found, it indicates a risky deletion operation. In this case, iterate through each dependent module and obtain the specific location in the module's code that references the deleted file. For example, if line 15, column 8 of src / components / UserProfile.js contains `import { formatDate} from '.. / utils / DateHelper'`, compile these code locations into a reference error report, output it to the developers, and simultaneously block commits. Then, after seeing the report, the developers will know that before deleting DateHelper, they must first delete this reference statement in UserProfile.js or change it to reference another file.

[0052] If no dependent modules are found, it means that although the file exists, no one in the project is using it anymore. In this case, it is safe to delete it, and there is no problem with dangling references. At this time, the file to be deleted is determined to be within the build scope, and the corresponding historical build artifacts will be cleaned up in subsequent incremental build phases.

[0053] 2) The change type is modified.

[0054] The modified file is used as the modified file, and the abstract syntax tree of the modified file before and after the modification is parsed. Match these two abstract syntax trees to locate and modify the corresponding code nodes; Determine the scope hierarchy of the code node in the modified abstract syntax tree; the scope hierarchy includes the exported interface hierarchy and the internal implementation hierarchy; If the scope level of the code node is the export interface level, then the file identifier of the modified file is determined, and the file identifier is used as the query key to query in the pre-built module dependency graph to determine the build scope; If the scope level of the code node is the internal implementation level, then only the modified file will be determined as the build scope.

[0055] Specifically, regarding the type of modification, we need to consider whether the file has been modified, but this modification only affects itself, or will it affect other files that depend on it? This depends on whether the modification is to the external interface or the internal implementation.

[0056] Therefore, by obtaining both the pre-commit and post-commit versions of the modified file, and analyzing the source code of both versions, two Abstract Syntax Trees (ASTs) are obtained. An AST is a structured representation of the source code, where each variable declaration, function definition, and class definition is a node. The two ASTs are then compared to identify which nodes have changed. For example, in the pre-commit version, the function `calculatePrice` returned `price`. In version 1.1, the modified version changed it to price. 1.15, then the AST node corresponding to this function is located as the code node involved in this modification.

[0057] In an Abstract Syntax Tree (AST), each node has a clearly defined scope, which is divided into two levels: the exported interface level and the internal implementation level. The exported interface level refers to the code node that is modified by the `export` keyword and is visible to external modules. For example, `export function calculatePrice()` is an exported interface, and other files in the project can call it using `import { calculatePrice}`. The internal implementation level refers to the code node that is not modified by `export` and is only used within the file, and cannot be directly accessed by external modules.

[0058] If the modification occurs at the exported interface level, it means the interface called by external dependencies has changed—for example, the function's parameter list, return type, or behavioral logic has changed. All modules that depend on this interface will be affected, and their compilation results may no longer be compatible with the new interface. If the modification occurs at the internal implementation level, such as modifying a private function used internally in a file (this function is not visible externally, and other files are unaware of its existence), then the impact of this modification is limited to the file itself. If the modification involves the exported interface level, the file identifier of the modified file is used as the lookup key to search the module dependency graph for all modules that depend on it, including not only directly dependent modules but also indirectly dependent modules—that is, modules that depend on direct dependencies. This is passed down layer by layer along the dependency chain, including these modules and the modified file in the build scope, ensuring that all files in the entire dependency chain are recompiled with the new interface to verify compatibility. If the modification only involves the internal implementation level, only the modified file itself is included in the build scope; other files do not need to be recompiled because the interface called by external modules has not changed, and the previously compiled artifacts remain valid.

[0059] 3) Change type to new type.

[0060] The modified file is treated as a new file. The file identifier of the new file is obtained, and the abstract syntax tree of the new file is parsed to extract each declaration node modified by the preset keyword in the abstract syntax tree. Obtain the export identifiers of each of the declared nodes to form a set of export interfaces; Iterate through all the other modified files except the newly added file, and determine whether the import declaration of any other modified file references the file identifier, and / or whether the identifier referenced in the import declaration of any other modified file matches any export identifier in the export interface set. If so, both the changed files and the newly added files will be included in the build scope.

[0061] Specifically, for newly added types, we need to consider: if a new file is added, besides the file itself needing to be compiled, are there any other modified files in this commit that reference it? If so, these files need to be compiled together with the newly added file.

[0062] Therefore, the file identifier of the newly added file is its path in the project. At the same time, the AST of the newly added file is parsed to find all the declaration nodes modified by the export keyword, such as export function foo() and export const bar = 1. The export identifiers (foo, bar) of these nodes are extracted to form a set of export interfaces. This set represents all the available interfaces exposed by the newly added file. This commit might not only add a new file but also modify other files. These modified files might contain new import statements for the new file. For example, the developer might add `src / api / newApi.js` and modify `src / components / App.js`, adding the line `import { fetchData} from '.. / api / newApi'` to `App.js`. The process iterates through these modified files (excluding the new file) and checks the import declarations for each. There are two conditions for a match: either the import declaration references the file identifier of the new file (i.e., the import path points to the new file), such as `import ... from '. / newApi'`, which, after path parsing, matches `src / api / newApi.js`; or the identifier referenced in the import declaration matches an identifier in the export interface set of the new file. For example, if the new file's export interface set contains `fetchData`, and a modified file's import declaration contains `import { fetchData} from ...`, then the identifiers match.

[0063] If a modified file matches a newly added file, it means that the modified file depends on the newly added file. The two are related at compile time, so the modified file and the newly added file are included in the build scope together to ensure that their interfaces match at compile time. If no modified file is matched, it means that the newly added file in this commit has not yet been referenced by other files, so only the newly added file itself is included in the build scope.

[0064] Furthermore, after determining the amended documents, this application may include the following steps: After identifying the documents that have been changed, the following is also included: The initial set of changed files consists of all the files that have undergone changes. Iterate through each changed file in the initial set of changed files and determine whether the file type of the changed file belongs to any of the preset build configuration file types. The build configuration file types include build tool configuration files, compilation option files, dependency declaration files, and environment variable configuration files. If so, a global configuration change marker is generated and appended to the initial set of change files to obtain the target set of change files.

[0065] Specifically, the previous steps have identified the files that have changed in this commit. These files form an initial set of changed files. This set has not yet been categorized or labeled and may contain various types of files—business code files, style files, configuration files, documentation files, etc. However, it is necessary to first determine whether there is a special type of file in this set. This type of file affects the build process differently than ordinary code files. Therefore, each changed file in the initial set of changed files is checked one by one. The criteria for checking is whether the file name or file path matches the preset build configuration file type. The build configuration file type specifically includes four categories: The first category is build tool configuration files, such as webpack.config.js, vite.config.js, and rollup.config.js. These files define the project's build process, entry file, output directory, module parsing rules, etc. Modifying these files means that the entire project's build rules may have changed. The second category is compiler option files, such as tsconfig.json, babel.config.js, and .babelrc. These files control how the compiler processes the source code, such as the target version of TypeScript, whether to enable strict mode, and how to handle JSX. Modifying compiler options will cause the compiler to process the same source code... The first category is dependency declaration files, such as `.env`, `.env.production`, and `.env.development`. These files define the names and versions of third-party packages that the project depends on. Modifying `.env`, such as upgrading the version of a dependency package, may introduce new APIs or deprecate old APIs, affecting the compilation results of all modules using that dependency package. The second category is environment variable configuration files, such as `.env`, `.env.production`, and `.env.development`. These files define the values ​​of environment variables during application runtime. During compilation, these variables are injected into the code. Modifying environment variables will cause the logical branches in the code that depend on these variables to produce different compilation outputs.

[0066] The common characteristic of these four types of files is that they themselves do not need to be compiled, and other files in the project will not use import statements to reference them. However, their content determines how the compiler compiles and what is compiled. If a source file's code remains unchanged, but the target in tsconfig.json is changed from ES5 to ES6, the compiled output will be completely different. Therefore, changes to build configuration files do not affect a specific file, but are global.

[0067] Therefore, if at least one file belonging to the build configuration file type is found in the initial change file set during the traversal, a global configuration change flag is generated. This flag is itself an identifier, such as a boolean value or an enumeration value. This flag is appended to the initial change file set to obtain the target change file set. If no build configuration file is found after the traversal, the flag is not generated, and the target change file set is identical to the initial change file set.

[0068] In other words, the premise of improved verification efficiency is that unchanged files do not need to be recompiled. This premise is valid only if the compilation rules have not changed. However, if the compilation rules have changed, even if the file content has not changed, recompilation may produce different results. Therefore, this application introduces the above-mentioned file type discrimination after the changed files are determined and before the build scope is determined. This is used to identify files with such global impact and adjust the subsequent build strategy through a marking mechanism to prevent defects that pass verification but actually have problems in the code.

[0069] Therefore, if a global configuration change marker is detected on the target change set before the incremental build, the build scope will be changed to a full build scope, meaning that all files in the project will be included in the build scope.

[0070] and Figure 1 Corresponding to the method described above, embodiments of the present invention also provide a pre-submission verification device for verifying... Figure 1 The specific implementation of the method, the code submission verification device provided in this embodiment of the invention, can be used on a computer terminal or various mobile devices, combined with Figure 2 The document introduces the verification mechanism before code submission, such as... Figure 2 As shown, the device may include: The context information capture module 10 is used to activate a pre-built hook script when the developer is detected to be performing a code submission operation, so that the hook script can verify and intercept the code submission operation and trigger the capture of context information corresponding to the code submission operation. The changed file determination module 20 is used to determine the changed file from the context information; The construction scope determination module 30 is used to analyze the change type of the changed file and determine the construction scope based on the change type; The compilation result determination module 40 is used to perform incremental construction on the constructed range in order to determine the compilation result; The judgment module 50 is used to block the code submission operation if the compilation result is a compilation failure, and to continue executing the code submission operation if the compilation result is a success.

[0071] As can be seen from the above technical solution, when this application detects a developer performing a code submission operation, it activates a pre-built hook script to verify and intercept the code submission operation, and triggers the capture of context information corresponding to the code submission operation; it determines the changed file from the context information; it analyzes the change type of the changed file and determines the build scope based on the change type; it performs incremental build on the built scope to determine the compilation result; if the compilation result is a compilation failure, it blocks the code submission operation; if the compilation result is a success, it continues to execute the code submission operation. This application intercepts code submissions from developers, captures context information, and identifies the changed files. This focuses attention on the altered parts, allowing incremental builds to be performed based on the actual impact of each changed file. This excludes unchanged parts that don't need recompilation and covers affected dependency files that weren't modified. Compilation is then performed only on the minimum necessary parts, shifting the focus from full builds to incremental builds, thus solving the efficiency problem of long full build times. Subsequent commits can then be determined based on the success or failure of the compilation results.

[0072] Furthermore, embodiments of this application provide a verification device before code submission. Optionally, Figure 3 The diagram shows the hardware structure of the verification device before code submission, for reference. Figure 3 The hardware structure of the verification device before code submission may include: at least one processor 01, at least one communication interface 02, at least one memory 03, and at least one communication bus 04.

[0073] In this embodiment, the number of processor 01, communication interface 02, memory 03 and communication bus 04 is at least one, and processor 01, communication interface 02 and memory 03 communicate with each other through communication bus 04.

[0074] Processor 01 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention.

[0075] Memory 03 may include high-speed RAM, and may also include non-volatile memory, such as at least one disk storage device.

[0076] The memory stores a program, which the processor can call. The program is used to execute the following pre-submission verification methods, including: When a developer is detected performing a code commit operation, a pre-built hook script is activated so that the hook script can verify and intercept the code commit operation and trigger the capture of context information corresponding to the code commit operation. The changed file is determined from the context information; Analyze the change types of the modified files and determine the build scope based on the change types; Incremental build is performed on the constructed scope to determine the compilation result; If the compilation result is a compilation failure, the code submission operation is blocked; if the compilation result is a success, the code submission operation continues.

[0077] Optionally, the detailed and extended functions of the program can be found in the description of the verification method before code submission in the method embodiment.

[0078] This application embodiment also provides a storage medium that can store a program suitable for execution by a processor. When the program runs, it controls the device where the storage medium is located to execute the following pre-submission verification method, including: When a developer is detected performing a code commit operation, a pre-built hook script is activated so that the hook script can verify and intercept the code commit operation and trigger the capture of context information corresponding to the code commit operation. The changed file is determined from the context information; Analyze the change types of the modified files and determine the build scope based on the change types; Incremental build is performed on the constructed scope to determine the compilation result; If the compilation result is a compilation failure, the code submission operation is blocked; if the compilation result is a success, the code submission operation continues.

[0079] Specifically, the storage medium can be a computer-readable storage medium, which can be an electronic storage device such as flash memory, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM, hard disk, or ROM.

[0080] Optionally, the detailed and extended functions of the program can be found in the description of the verification method before code submission in the method embodiment.

[0081] Furthermore, the functional modules in the various embodiments of this disclosure can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part. If the function is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a live streaming device, or a network device, etc.) to execute all or part of the steps of the methods in the various embodiments of this disclosure.

[0082] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0083] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0084] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for verifying code before submission, characterized in that, include: When a developer is detected performing a code commit operation, a pre-built hook script is activated so that the hook script can verify and intercept the code commit operation and trigger the capture of context information corresponding to the code commit operation. The changed file is determined from the context information; Analyze the change types of the modified files and determine the build scope based on the change types; Incremental build is performed on the constructed scope to determine the compilation result; If the compilation result is a compilation failure, the code submission operation is blocked; if the compilation result is a success, the code submission operation continues.

2. The method according to claim 1, characterized in that, The activation of the pre-built hook script includes: Obtain the names of the pre-built hook scripts and the names of each original hook script in the local script directory; Determine whether an original hook script with the same name as the pre-built hook script exists in the local script directory; If so, the execution logic of the pre-built hook script is added to the original hook script with the same name, and the execution order is set as follows: first execute the execution logic of the original hook script, and then execute the logic of the pre-built hook script.

3. The method according to claim 1, characterized in that, The step of determining the changed file from the context information includes: Extract the file list and commit message from the context information; The submission message is segmented to obtain submission intent keywords; For each file in the file list, extract the file name, file path, and specific changes made to that file; Calculate the relevance score between the file and the submitted intent keywords based on the file name, file path, and specific changes; Files with a relevance score higher than the preset relevance threshold are considered as files that have been changed.

4. The method according to claim 1, characterized in that, Determining the build scope based on the change type includes: If the change type is deletion, then the file that has been changed is treated as a deleted file, and the file identifier of the deleted file is determined. The file identifier is used as the query key to query the pre-built module dependency graph to determine whether there is a dependent module in the module dependency graph that declares a dependency relationship with the deleted file. If no dependent modules that declare a dependency on the deleted file are found, the deleted file will be used as the build scope.

5. The method according to claim 1, characterized in that, The build scope is determined based on the change type, including: If the change type is modification type, then the file that has been changed is treated as the modified file, and the abstract syntax tree of the modified file before modification and the abstract syntax tree after modification are parsed. Match these two abstract syntax trees to locate and modify the corresponding code nodes; Determine the scope hierarchy of the code node in the modified abstract syntax tree; the scope hierarchy includes the exported interface hierarchy and the internal implementation hierarchy; If the scope level of the code node is the export interface level, then the file identifier of the modified file is determined, and the file identifier is used as the query key to query in the pre-built module dependency graph to determine the build scope; If the scope level of the code node is the internal implementation level, then only the modified file will be determined as the build scope.

6. The method according to any one of claims 1 to 5, characterized in that, The build scope is determined based on the change type, including: If the change type is a new type, then the changed file is treated as a new file, the file identifier of the new file is obtained, and the abstract syntax tree of the new file is parsed to extract each declaration node modified by the preset keyword in the abstract syntax tree. Obtain the export identifiers of each of the declared nodes to form a set of export interfaces; Iterate through all the other modified files except the newly added file, and determine whether the import declaration of any other modified file references the file identifier, and / or whether the identifier referenced in the import declaration of any other modified file matches any export identifier in the export interface set. If so, both the changed files and the newly added files will be included in the build scope.

7. The method according to any one of claims 1 to 5, characterized in that, After identifying the documents that have been changed, the following is also included: The initial set of changed files consists of all the files that have undergone changes. Iterate through each changed file in the initial set of changed files and determine whether the file type of the changed file belongs to any of the preset build configuration file types. The build configuration file types include build tool configuration files, compilation option files, dependency declaration files, and environment variable configuration files. If so, a global configuration change marker is generated and appended to the initial set of change files to obtain the target set of change files.

8. A verification device for code submission, characterized in that, include: The context information capture module is used to activate a pre-built hook script when a developer is detected to be performing a code submission operation. The hook script then verifies and intercepts the code submission operation and triggers the capture of context information corresponding to the code submission operation. The changed file determination module is used to determine the changed file from the context information; A scope determination module is used to analyze the change type of the modified file and determine the scope of construction based on the change type; The compilation result determination module is used to perform incremental builds on the constructed scope to determine the compilation result. The judgment module is used to block the code submission operation if the compilation result is a compilation failure, and to continue executing the code submission operation if the compilation result is a success.

9. A verification device for code submission, characterized in that, Including memory and processor; The memory is used to store programs; The processor is configured to execute the program to implement each step of the code submission verification method as described in any one of claims 1-7.

10. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the code submission verification method as described in any one of claims 1-7.

Images