Code defect early warning method, device and equipment

Abstract

The embodiment of the invention provides a code defect early warning method, device and equipment. The method comprises the steps of obtaining a current submitted code in response to a code submission event; performing static detection on the submitted code, and determining an identifier of a defect code corresponding to the submitted code; matching the identification of the defect code with the identification of the changed code corresponding to the submitted code; and if the identification of the defect code comprises at least part of the identification of the changed code, performing code defect early warning on the submitted code so as to prohibit the submitted code from being combined to the main line code branch. In this way, before the submitted code is combined to the main line code branch, the defect code in the submitted code can be detected as soon as possible, and it is avoided that the defect of the submitted code can only be found in the later function test stage after the submitted code is combined to the main line code branch.

Description

Technical Field

[0001] The present disclosure relates to the field of codes, and in particular to the field of code detection technology. Background Art

[0002] Currently, the new code uploaded by developers is not tested before being merged into the main code branch. The code defects of the new code are often discovered in the later functional testing stage. However, such code defects are often generated in the design stage. The new code merged into the main code branch has the possibility of code defects. If the new code in the submitted code is not checked for defects and directly merged into the main code branch, it means that some unknown code defects are buried. These code defects can only be discovered in the later functional testing stage. The later the code defects are discovered, the higher the cost, and it grows exponentially. Summary of the invention

[0003] The present disclosure provides a code defect early warning method, apparatus, device, storage medium and vehicle.

[0004] According to a first aspect of the present disclosure, a code defect early warning method is provided. The method comprises:

[0005] In response to a code submission event, obtain the submitted code;

[0006] Performing static detection on the currently submitted code to determine an identifier of a defect code corresponding to the currently submitted code;

[0007] Matching the identifier of the defect code with the identifier of the change code corresponding to the currently submitted code;

[0008] If the identifier of the defective code includes at least part of the identifier of the changed code, a code defect warning is issued for the currently submitted code to prohibit merging the currently submitted code into the mainline code branch.

[0009] According to the above aspects and any possible implementation manner, an implementation manner is further provided, wherein in response to a code submission event, obtaining the submitted code includes:

[0010] Obtaining a unique code pull identifier corresponding to the submitted code contained in the code submission event;

[0011] The unique code pull identifier is called to pull the currently submitted code from a preset code repository, wherein the preset code repository stores the mainline code branch.

[0012] According to the above aspects and any possible implementation manner, an implementation manner is further provided, before statically checking the submitted code, the method further includes:

[0013] Call the pre-installed code management tool;

[0014] The management instruction corresponding to the code management tool is used to extract the identifier of the changed code corresponding to the code submitted this time.

[0015] According to the above aspects and any possible implementation, there is further provided an implementation, wherein the management instruction includes: a node rollback instruction, a code comparison instruction, and an identification acquisition instruction;

[0016] The extracting the identifier of the changed code corresponding to the submitted code by using the management instruction corresponding to the code management tool includes:

[0017] Utilize the node rollback instruction to query the last submitted code corresponding to the currently submitted code;

[0018] Using the code comparison instruction, the last submitted code is compared with the current submitted code to determine the change code of the current submitted code compared with the last submitted code;

[0019] The identifier is used to obtain the instruction and extract the identifier of the changed code, wherein the changed code includes: new code and / or modified code, and the identifier of the changed code includes at least one of the following: the file name of the new code, the line number of the new code, and the line number of the modified code.

[0020] According to the above aspect and any possible implementation manner, an implementation manner is further provided, wherein the static detection of the currently submitted code to determine the identifier of the defect code corresponding to the currently submitted code includes:

[0021] Call the pre-installed code static detection tool;

[0022] The preset configuration file of the code submitted this time is accessed through the code static detection tool to parse the code submitted this time through the preset configuration file to determine the defect code and the identifier of the defect code, wherein the preset configuration file is a header file of the code submitted this time, and the preset configuration file includes variable declarations, function declarations and macro definitions in the code submitted this time.

[0023] According to the above aspects and any possible implementation, a further implementation is provided, if there is more than one identification of the defect code and the identification of the change code, then

[0024] The matching of the identifier of the defect code with the identifier of the change code corresponding to the currently submitted code includes:

[0025] Compare the identifiers of the defect code with the identifiers of the change code corresponding to the currently submitted code to determine whether the identifiers of the change code exist in the identifiers of the defect code;

[0026] If the identifier of the defective code includes at least part of the identifier of the changed code, a code defect warning is performed on the submitted code, including:

[0027] If part of the identifiers of the changed code exist in the identifiers of the defect code, or if the identifiers of the defect code are completely identical to the identifiers of the changed code, a code defect warning is issued for the code submitted this time.

[0028] According to the above aspects and any possible implementation manner, an implementation manner is further provided, wherein the performing code defect warning on the currently submitted code includes:

[0029] Based on the at least part of the identification, issuing a code defect warning;

[0030] It is prohibited to submit the submitted code to a preset code repository, wherein the mainline code branch is stored in the preset code repository.

[0031] According to a second aspect of the present disclosure, a code defect early warning device is provided. The device comprises:

[0032] An acquisition module, used to respond to a code submission event and obtain the submitted code;

[0033] A determination module, configured to perform static detection on the currently submitted code to determine an identifier of a defect code corresponding to the currently submitted code;

[0034] A matching module, used to match the identifier of the defect code with the identifier of the change code corresponding to the currently submitted code;

[0035] The early warning module is used to issue a code defect early warning for the code submitted this time if the identifier of the defective code includes at least part of the identifier of the changed code.

[0036] According to a third aspect of the present disclosure, an electronic device is provided, which includes a memory and a processor, wherein a computer program is stored in the memory, and when the processor executes the program, the method described above is implemented.

[0037] According to a fourth aspect of the present disclosure, a computer-readable storage medium is provided, on which a computer program is stored. When the program is executed by a processor, the method according to the first aspect of the present disclosure is implemented.

[0038] According to a fifth aspect of the present disclosure, a vehicle is provided, the vehicle comprising the code defect warning device as described in the second aspect and / or the electronic device as described in the third aspect.

[0039] In the present disclosure, after obtaining the code submission event, the developer's submitted code can be obtained in response to the code submission event, and then the submitted code can be statically detected to determine the defect code corresponding to the submitted code and the identifier of the defect code, and then the identifier of the defect code is matched with the identifier of the change code corresponding to the submitted code to determine whether the identifier of the defect code has the corresponding identifier of the change code. If the identifier of the defect code includes at least part of the identifier of the change code, it means that the defect code does belong to the newly added code of the submitted code, that is, the submitted code is defective. Therefore, a code defect warning can be issued for the submitted code to prohibit the merging of the submitted code into the mainline code branch. In this way, the defective code in the submitted code can be detected early in the code design stage before the submitted code is merged into the mainline code branch, so as to avoid the defects of the submitted code being discovered only in the later functional testing stage after being merged into the mainline code branch. In this way, the cost of checking code defects is also reduced.

[0040] It should be understood that the contents described in the summary of the invention are not intended to limit the key or important features of the embodiments of the present disclosure, nor are they intended to limit the scope of the present disclosure. Other features of the present disclosure will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] The above and other features, advantages and aspects of the embodiments of the present disclosure will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. The accompanying drawings are used to better understand the present solution and do not constitute a limitation of the present disclosure. In the accompanying drawings, the same or similar reference numerals represent the same or similar elements, among which:

[0042] Figure 1 A flowchart of a code defect early warning method according to an embodiment of the present disclosure is shown;

[0043] Figure 2 A block diagram of a code defect early warning system according to an embodiment of the present disclosure is shown;

[0044] Figure 3 A schematic diagram showing an identifier in a code submission event according to an embodiment of the present disclosure is shown;

[0045] Figure 4 A flowchart of another code defect early warning method according to an embodiment of the present disclosure is shown;

[0046] Figure 5 A block diagram of a code defect early warning device according to an embodiment of the present disclosure is shown;

[0047] Figure 6 A block diagram of an exemplary electronic device capable of implementing embodiments of the present disclosure is shown. DETAILED DESCRIPTION

[0048] In order to make the purpose, technical solution and advantages of the embodiments of the present disclosure clearer, the technical solution in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the drawings in the embodiments of the present disclosure. Obviously, the described embodiments are part of the embodiments of the present disclosure, not all of the embodiments. Based on the embodiments in the present disclosure, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present disclosure.

[0049] In addition, the term "and / or" in this article is only a description of the association relationship between the associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this article generally indicates that the associated objects before and after are in an "or" relationship.

[0050] Figure 1 The flowchart of the code defect early warning method 100 according to the embodiment of the present disclosure is shown. The execution subject of the method 100 may be a server with Jenkins installed, that is, a Jenkins continuous integration platform, wherein Jenkins is an open source software project and a continuous integration tool developed based on Java. The method may include:

[0051] Step 110, in response to the code submission event, obtaining the submitted code;

[0052] The code submission event includes a unique code pull identifier, through which the submitted code can be automatically pulled from the preset code repository.

[0053] The code submission event comes from the Gerrit code server (Gerrit is a web code review tool based on the git version control system. It is also a free, open source code review software that uses a web interface). The Gerrit code server has a preset code repository, which is used to store the code uploaded by each developer. Developers can upload the submitted code to the Gerrit code server through the git push command, such as Figure 2As shown; of course, the code uploaded this time is the code submitted this time.

[0054] The code submission event can be a Jenkins event. The Gerrit code server can notify the Jenkins continuous integration platform of the code submission event through webhook. Webhook is an API concept and one of the usage paradigms of microservice API. It is also called reverse API, that is, the front end does not actively send requests, but is completely pushed by the back end. For example, if your friend posts a circle of friends, the back end pushes this message to all other friends' clients, which is a typical scenario of Webhook.

[0055] In addition, the Gerrit code server and the server on which Jenkins is installed can be the same server or different servers, and this disclosure does not impose any limitation.

[0056] Step 120, statically checking the submitted code to determine the identifier of the defect code corresponding to the submitted code;

[0057] Static testing means checking the correctness of a program by analyzing or checking the syntax, structure, process, interface, etc. of the source program without running the program itself.

[0058] The identifier includes but is not limited to the file name and line number of the file to which the code belongs.

[0059] Defective code refers to code that contains errors in syntax, semantics, structure, interface, etc.

[0060] The defect code corresponding to the submitted code refers to the defect code in the submitted code.

[0061] Step 130, matching the identifier of the defect code with the identifier of the change code corresponding to the currently submitted code;

[0062] Changed code refers to the difference between the code submitted this time and the code submitted last time, including the newly added code and the modified code between the code submitted this time and the code submitted last time.

[0063] The last submitted code is the code that was most recently received and stored in the preset code repository on the Gerrit code server in addition to the code submitted this time. It is also the code that the Gerrit code server most recently allowed to be merged into the preset code repository. Of course, the last submitted code and the code submitted this time can be submitted by the same developer or by different developers.

[0064] Step 140: If the identifier of the defective code includes at least part of the identifier of the changed code, a code defect warning is issued for the currently submitted code to prohibit merging the currently submitted code into the mainline code branch.

[0065] That the identifier of the defect code includes at least part of the identifier of the changed code means that the identifier of the defect code includes part of the identifier of the changed code or includes all the identifiers of the changed code.

[0066] The mainline code branch is stored in the default code repository.

[0067] In addition, the mainline code branch will change continuously as the development progresses. For example, if the development stages of a project are specified as A development stage, B development stage, C development stage, and D development stage, then the mainline branch of A development stage is A mainline branch, the mainline branch of B development stage is B mainline branch, the mainline branch of C development stage is C mainline branch, and the mainline branch of D development stage is D mainline branch. All the code of A mainline branch that has been stored and merged together in the preset code repository is A mainline code branch, all the code of B mainline branch that has been stored and merged together in the preset code repository is B mainline code branch, all the code of C mainline branch that has been stored and merged together in the preset code repository is C mainline code branch, and all the code of D mainline branch that has been stored and merged together in the preset code repository is D mainline code branch.

[0068] In response to the code submission event, the developer's submitted code can be obtained, and then the submitted code can be statically detected to determine the defect code corresponding to the submitted code and the identifier of the defect code, and then the identifier of the defect code can be matched with the identifier of the change code corresponding to the submitted code to determine whether the identifier of the defect code has the identifier of the change code. If the identifier of the defect code includes at least part of the identifier of the change code, it means that the defect code does belong to the submitted code, that is, the submitted code is defective. Therefore, a code defect warning can be issued for the submitted code to prohibit the merging of the submitted code into the mainline code branch. In this way, the defective code in the submitted code can be detected early before the submitted code is merged into the mainline code branch, so as to avoid the defects of the submitted code being discovered in the later functional testing stage after being merged into the mainline code branch. This also reduces the cost of checking code defects.

[0069] In one embodiment, in response to a code submission event, obtaining the submitted code includes:

[0070] Obtaining a unique code pull identifier corresponding to the submitted code contained in the code submission event;

[0071] The unique code pull identifier corresponding to the code submission event is used to pull the code. The unique code pull identifier may be a refs change id.

[0072] The unique code pull identifier is called to pull the currently submitted code from a preset code repository, wherein the preset code repository stores the mainline code branch.

[0073] By obtaining the unique code pull identifier corresponding to the submitted code contained in the code submission event, the unique code pull identifier can be called to automatically pull the submitted code from the preset code repository.

[0074] You can use the following git command to pull the submitted code from the preset code repository, i.e. the gerrit repository:

[0075] git pull ssh: / / xxx@gerrit.it.xxxxxx.com:29418 / cpd / bsd / FBCM / refs / changes / 54 / 619554 / 1

[0076] xx is the developer's account, gerrit.it.xxxxxx.com:29418 / cpd / bsd / FBCM is the storage path of the submitted code on the execution entity, and refs / changes / 54 / 619554 / 1 is the unique code pull identifier.

[0077] In one embodiment, before statically checking the submitted code, the method further includes:

[0078] Call the pre-installed code management tool;

[0079] The code management tool may be a git tool, which is used to manage the code.

[0080] The management instructions include but are not limited to: node rollback instructions, code comparison instructions, and identification acquisition instructions.

[0081] Each submitted code is a node, and the last submitted code is the parent node of the current submitted code, and the current submitted code is the child node of the last submitted code.

[0082] The management instruction corresponding to the code management tool is used to extract the identifier of the changed code corresponding to the code submitted this time.

[0083] By calling the code management tool, the management instructions corresponding to the code management tool can be used to automatically extract the change code corresponding to the code submitted this time and the identifier of the change code, so as to determine the new code and modified code of the code submitted this time relative to the code submitted last time and the identifier of the new code and modified code.

[0084] In one embodiment, the management instructions include: a node rollback instruction, a code comparison instruction, and an identification acquisition instruction;

[0085] The extracting the identifier of the changed code corresponding to the submitted code by using the management instruction corresponding to the code management tool includes:

[0086] Utilize the node rollback instruction to query the last submitted code corresponding to the currently submitted code;

[0087] The node rollback instruction is used to roll back to the last submitted code, but it is not necessary to pull the last submitted code to the local. Specifically, the node rollback instruction can be git reset Head~1, where Head refers to the current node to which the currently submitted code belongs, and ~1 is used to return to the previous node of the current node, that is, the last submitted code. Therefore, after executing the node rollback instruction, the git node will be rolled back from the current node to which the currently submitted code belongs to the node of the last submitted code, and the contents of the folder in the storage path where the currently submitted code is located will be retained (that is, the currently submitted code will be retained).

[0088] Using the code comparison instruction, the last submitted code is compared with the current submitted code to determine the change code of the current submitted code compared with the last submitted code;

[0089] The code comparison instruction is used to compare the code submitted this time with the code submitted last time to accurately determine the changed code.

[0090] For example, the code comparison command can be git status, which can obtain the difference between the code in the folder of the storage path where the code is submitted this time (that is, the code submitted this time) and the previous node (that is, the code submitted last time), thereby identifying the changed or newly added files, that is, the changed code.

[0091] The identifier is used to obtain the instruction and extract the identifier of the changed code, wherein the changed code includes: new code and / or modified code, and the identifier of the changed code includes at least one of the following: the file name of the new code, the line number of the new code, and the line number of the modified code.

[0092] The logo acquisition command can automatically and accurately extract the logo of the changed code. For example:

[0093] The identification acquisition instruction may be a git diff command. By using the git diff command for the changed files, the line number and file name of the specific changes may be obtained.

[0094] By utilizing the node rollback instruction, the last submitted code can be automatically queried, and then after executing the code comparison instruction, the last submitted code can be automatically compared with the currently submitted code to accurately determine the changed code of the currently submitted code compared to the last submitted code, and then the identifier is used to obtain the instruction to accurately extract the identifier of the changed code, so as to clarify which lines have been specifically changed or which codes have been added in the currently submitted code compared to the last submitted code.

[0095] In one embodiment, the static detection of the currently submitted code to determine the identifier of the defect code corresponding to the currently submitted code includes:

[0096] Call the pre-installed code static detection tool;

[0097] Code static detection tools include but are not limited to: Helix QAC tool, among which Helix QAC is a product of Perforce (formerly PRQA), mainly used for fully automated static analysis of C / C++ codes, and can provide coding rule checking, code quality measurement, software structure analysis, test result management and other functions.

[0098] The preset configuration file of the submitted code is accessed through the code static detection tool to parse the submitted code through the preset configuration file to determine the defect code and the identifier of the defect code, wherein the preset configuration file is the header file of the submitted code, and the preset configuration file includes variable declarations, function declarations and macro definitions in the submitted code. The defect code and the identifier of the defect code are the QAC-verify result.

[0099] By calling a pre-installed code static detection tool, the code static detection tool can be run to access the preset configuration file, so that the submitted code can be fully and accurately analyzed with the assistance of the preset configuration file to accurately identify the defective code in the submitted code and the identifier of the defective code.

[0100] In one embodiment, if there is more than one identification of the defect code and the identification of the change code, then

[0101] The matching of the identifier of the defect code with the identifier of the change code corresponding to the currently submitted code includes:

[0102] Compare the identifiers of the defect code with the identifiers of the change code corresponding to the currently submitted code to determine whether the identifiers of the change code exist in the identifiers of the defect code;

[0103] If the identifier of the defective code includes at least part of the identifier of the changed code, a code defect warning is performed on the submitted code, including:

[0104] If part of the identifiers of the changed code exist in the identifiers of the defect code, or if the identifiers of the defect code are completely identical to the identifiers of the changed code, a code defect warning is issued for the code submitted this time.

[0105] Since the defective code and the changed code may be more than one line or one file, and therefore, there is more than one identifier of the defective code and the identifier of the changed code. Therefore, by comparing the identifiers of the defective code with the identifiers of the changed code corresponding to the code submitted this time, it is possible to automatically determine whether the identifiers of the changed code exist in the identifiers of the defective code. If some identifiers of the changed code exist in the identifiers of the defective code, or the identifiers of the defective code are exactly the same as the identifiers of the changed code, it means that the defective code belongs to the code submitted this time, that is, the code submitted this time is defective. Therefore, it is necessary to automatically and accurately issue a code defect warning for the code submitted this time.

[0106] For example, the identifiers of the defect code are line 60 and line 81, and the identifiers of the change code are line 70 to line 90. Since the identifiers of the defect code only include line 81 of the change code, partial identifiers of the change code exist in the identifiers of the defect code.

[0107] For another example, if the identifiers of the defective code are lines 90-110, and the modified code is also lines 90-110, then it is confirmed that the identifiers of the defective code are completely identical to the identifiers of the modified code.

[0108] In one embodiment, the performing code defect warning on the submitted code includes:

[0109] Based on the at least part of the identification, issuing a code defect warning;

[0110] It is prohibited to submit the submitted code to a preset code repository, wherein the mainline code branch is stored in the preset code repository.

[0111] By issuing a code defect warning based on at least part of the identification, the person who receives the code defect warning can not only clearly know that the code submitted this time is defective, but also clearly know which part of the code is defective. Of course, it is also necessary to prohibit the submission of the submitted code this time to the preset code repository, thereby prohibiting the merging of the submitted code this time into the main line code branch.

[0112] The following will be combined Figures 2 to 4 The technical solution of the present disclosure is further described in detail:

[0113] The first step is to configure the Jenkins continuous integration platform so that when the code submitter submits the code to the preset code repository of the Gerrit code server through the git push Git command, the Gerrit code server will notify the Jenkins continuous integration platform through webhook. The Jenkins continuous integration platform can obtain various Git parameter information of the submitted code and automatically execute an event, such as Figure 2 shown.

[0114] The second step is to obtain various git parameters of this code submission, commit id, refs change id and git parent id (such as Figure 3 As shown, commit id: the unique code storage identifier corresponding to the submitted code, which is used to generate the storage path of the submitted code on the execution subject, refschangeid: the unique digital identifier corresponding to the code modification item, through which the code submitted can be pulled with the fixed git command, that is, the refs change id is the unique code pull identifier

[0115] parent id: the unique numeric identifier of the parent node (diamagnetic of the last commit) of the current node to which the code to be committed belongs. Through these parameters, the code that is exactly the same as the current commit is obtained in the specific path of the Jenkins server (the storage path where the code to be committed is stored on the execution body).

[0116] In the third step, although the code that is exactly the same as the current submission is obtained in the specific path of the server, it is still impossible to identify the changes or newly added code files (i.e. changed code) between the current submission and the previous code, as well as the specific changed line numbers in these files (i.e. code identification). These problems can be identified and obtained through a series of Git commands, and then automatically identified with the help of Python.

[0117] The fourth step is to identify the newly added or changed files and the line numbers of the specific file changes, and then use Python to obtain the header file path of the submitted code to determine the header file of the submitted code. Then call the Helix QAC software kernel through Python, and use the variable declarations, function declarations and macro definitions in the header file of the submitted code to perform static code scanning on the submitted code.

[0118] The fifth step, after scanning the QAC results (i.e., QAC-verify results), use Python to obtain the source files and line numbers corresponding to these scan results. If these source files and line numbers correspond to the newly added or changed files and line numbers in the code submitted this time, save these results and pass them to the Gerrrit server with a failure mark through the Jenkins event execution result. If there is no corresponding result, pass it to the Gerrrit server with a success mark. The Gerrit server uses this marking result to decide whether the code can be merged into the main branch. If it is a success mark, the code is allowed to merge into the main branch. If it is a failure mark, the code is prohibited from merging into the main branch, and an alarm is sent to the corresponding code submitter through Feishu and email, such as Figure 4 shown.

[0119] After applying this disclosure, code testing can be moved forward. The code in the Gerrit server that needs to be merged into the main branch will undergo a static code scan to identify code defects in advance, which is conducive to solving code defects early, greatly improving the quality of the uploaded code and the efficiency of solving problems, and affecting the team's effectiveness in the long run.

[0120] It should be noted that, for the aforementioned method embodiments, for the sake of simplicity, they are all described as a series of action combinations, but those skilled in the art should be aware that the present disclosure is not limited by the order of the actions described, because according to the present disclosure, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily required by the present disclosure.

[0121] The above is an introduction to the method embodiment. The following is a further explanation of the scheme disclosed in the present invention through an apparatus embodiment.

[0122] Figure 5 FIG. 5 shows a block diagram of a code defect early warning device 500 according to an embodiment of the present disclosure. Figure 5 As shown, the device 500 includes:

[0123] The acquisition module 510 is used to respond to the code submission event and obtain the submitted code;

[0124] The determination module 520 is used to perform static detection on the currently submitted code to determine the identifier of the defect code corresponding to the currently submitted code;

[0125] A matching module 530, configured to match the identifier of the defect code with the identifier of the change code corresponding to the currently submitted code;

[0126] The warning module 540 is configured to issue a code defect warning to the currently submitted code if the identifier of the defective code includes at least part of the identifier of the changed code.

[0127] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the described module can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0128] According to an embodiment of the present disclosure, the present disclosure further provides an electronic device, including:

[0129] at least one processor; and

[0130] a memory communicatively connected to the at least one processor; wherein,

[0131] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can perform any of the above method embodiments.

[0132] According to an embodiment of the present disclosure, the present disclosure further provides a vehicle, comprising: a code defect warning device as described in the above embodiment or an electronic device as described in the above embodiment.

[0133] According to an embodiment of the present disclosure, the present disclosure further provides a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to enable the computer to execute any one of the above method embodiments.

[0134] Figure 6 A schematic block diagram of an electronic device 600 that can be used to implement an embodiment of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present disclosure described and / or required herein.

[0135] The device 600 includes a computing unit 601, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 602 or a computer program loaded from a storage unit 608 into a random access memory (RAM) 603. In the RAM 603, various programs and data required for the operation of the device 600 can also be stored. The computing unit 601, the ROM 602, and the RAM 603 are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0136] A number of components in the device 600 are connected to the I / O interface 605, including: an input unit 606, such as a keyboard, a mouse, etc.; an output unit 607, such as various types of displays, speakers, etc.; a storage unit 608, such as a disk, an optical disk, etc.; and a communication unit 609, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 609 allows the device 600 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks.

[0137] The computing unit 601 may be a variety of general and / or special processing components with processing and computing capabilities. Some examples of the computing unit 601 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various dedicated artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, digital signal processors (DSPs), and any appropriate processors, controllers, microcontrollers, etc. The computing unit 601 performs the various methods and processes described above, such as method 100. For example, in some embodiments, the method 100 may be implemented as a computer software program, which is tangibly contained in a machine-readable medium, such as a storage unit 608. In some embodiments, part or all of the computer program may be loaded and / or installed on the device 600 via the ROM 602 and / or the communication unit 609. When the computer program is loaded into the RAM 603 and executed by the computing unit 601, one or more steps of the method 100 described above may be performed. Alternatively, in other embodiments, the computing unit 601 may be configured to perform the method 100 in any other appropriate manner (e.g., by means of firmware).

[0138] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include: being implemented in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0139] The program code for implementing the method of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing device, so that the program code, when executed by the processor or controller, enables the functions / operations specified in the flow chart and / or block diagram to be implemented. The program code may be executed entirely on the machine, partially on the machine, partially on the machine and partially on a remote machine as a stand-alone software package, or entirely on a remote machine or server.

[0140] In the context of the present disclosure, a machine-readable medium may be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, device, or equipment. A machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or equipment, or any suitable combination of the foregoing. A more specific example of a machine-readable storage medium may include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0141] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Other types of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including acoustic input, voice input, or tactile input).

[0142] The systems and techniques described herein may be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user computer with a graphical user interface or a web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such back-end components, middleware components, or front-end components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), and the Internet.

[0143] A computing system may include a client and a server. The client and the server are generally remote from each other and usually interact through a communication network. The relationship of client and server is generated by computer programs running on respective computers and having a client-server relationship with each other. The server may be a cloud server, a server of a distributed system, or a server combined with a blockchain.

[0144] It should be understood that the various forms of processes shown above can be used to reorder, add or delete steps. For example, the steps recorded in this disclosure can be executed in parallel, sequentially or in different orders, as long as the desired results of the technical solutions disclosed in this disclosure can be achieved, and this document does not limit this.

[0145] The above specific implementations do not constitute a limitation on the protection scope of the present disclosure. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions can be made according to design requirements and other factors. Any modification, equivalent substitution and improvement made within the spirit and principle of the present disclosure shall be included in the protection scope of the present disclosure.

Claims

1. A code defect early warning method, characterized in that: include: In response to a code submission event, obtain the submitted code; Performing static detection on the currently submitted code to determine an identifier of a defect code corresponding to the currently submitted code; Matching the identifier of the defect code with the identifier of the change code corresponding to the currently submitted code; If the identifier of the defective code includes at least part of the identifier of the changed code, a code defect warning is issued for the currently submitted code to prohibit merging the currently submitted code into the mainline code branch.

2. The method according to claim 1, characterized in that The step of obtaining the submitted code in response to the code submission event includes: Obtaining a unique code pull identifier corresponding to the submitted code contained in the code submission event; The unique code pull identifier is called to pull the currently submitted code from a preset code repository, wherein the preset code repository stores the mainline code branch.

3. The method according to claim 1, characterized in that Before performing static detection on the submitted code, the method further includes: Call the pre-installed code management tool; The management instruction corresponding to the code management tool is used to extract the identifier of the changed code corresponding to the code submitted this time.

4. The method according to claim 3, characterized in that The management instructions include: node return instructions, code comparison instructions and identification acquisition instructions; The extracting the identifier of the changed code corresponding to the submitted code by using the management instruction corresponding to the code management tool includes: Utilize the node rollback instruction to query the last submitted code corresponding to the currently submitted code; Using the code comparison instruction, the last submitted code is compared with the current submitted code to determine the change code of the current submitted code compared with the last submitted code; The identifier is used to obtain the instruction and extract the identifier of the changed code, wherein the changed code includes: new code and / or modified code, and the identifier of the changed code includes at least one of the following: the file name of the new code, the line number of the new code, and the line number of the modified code.

5. The method according to claim 1, characterized in that The static detection of the currently submitted code to determine the identifier of the defect code corresponding to the currently submitted code includes: Call the pre-installed code static detection tool; The preset configuration file of the code submitted this time is accessed through the code static detection tool to parse the code submitted this time through the preset configuration file to determine the defect code and the identifier of the defect code, wherein the preset configuration file is a header file of the code submitted this time, and the preset configuration file includes variable declarations, function declarations and macro definitions in the code submitted this time.

6. The method according to claim 1, characterized in that If there is more than one identification of the defect code and the identification of the change code, then The matching of the identifier of the defect code with the identifier of the change code corresponding to the currently submitted code includes: Compare the identifiers of the defect code with the identifiers of the change code corresponding to the currently submitted code to determine whether the identifiers of the change code exist in the identifiers of the defect code; If the identifier of the defective code includes at least part of the identifier of the changed code, a code defect warning is performed on the submitted code, including: If part of the identifiers of the changed code exist in the identifiers of the defect code, or if the identifiers of the defect code are completely identical to the identifiers of the changed code, a code defect warning is issued for the currently submitted code.

7. The method according to any one of claims 1 to 6, characterized in that The code defect warning for the submitted code includes: Based on the at least part of the identification, issuing a code defect warning; It is prohibited to submit the submitted code to a preset code repository, wherein the mainline code branch is stored in the preset code repository.

8. A code defect early warning device, characterized in that: include: An acquisition module, used to respond to a code submission event and obtain the submitted code; A determination module, configured to perform static detection on the currently submitted code to determine an identifier of a defect code corresponding to the currently submitted code; A matching module, used to match the identifier of the defect code with the identifier of the change code corresponding to the currently submitted code; The early warning module is used to issue a code defect early warning for the code submitted this time if the identifier of the defective code includes at least part of the identifier of the changed code.

9. An electronic device, characterized in that: include: at least one processor; as well as a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1 to 7.

10. A vehicle, characterized in that: include: The code defect warning device as claimed in claim 8, and / or the electronic device as claimed in claim 9.

Images