CN117573564B - 一种基于gitlab代码提交日志自动识别差异的方法 - Google Patents
一种基于gitlab代码提交日志自动识别差异的方法 Download PDFInfo
- Publication number
- CN117573564B CN117573564B CN202410055725.4A CN202410055725A CN117573564B CN 117573564 B CN117573564 B CN 117573564B CN 202410055725 A CN202410055725 A CN 202410055725A CN 117573564 B CN117573564 B CN 117573564B
- Authority
- CN
- China
- Prior art keywords
- tag
- version
- log
- gitlab
- commit
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 30
- 238000010276 construction Methods 0.000 claims abstract description 49
- 238000012360 testing method Methods 0.000 claims abstract description 35
- 238000004422 calculation algorithm Methods 0.000 claims abstract description 8
- 238000007405 data analysis Methods 0.000 claims description 7
- 210000000056 organ Anatomy 0.000 claims description 7
- 230000008439 repair process Effects 0.000 claims description 3
- 238000013515 script Methods 0.000 claims description 3
- 238000012163 sequencing technique Methods 0.000 claims description 3
- 238000004458 analytical method Methods 0.000 claims description 2
- 238000004590 computer program Methods 0.000 claims description 2
- 238000010586 diagram Methods 0.000 description 14
- 230000006870 function Effects 0.000 description 5
- 238000011161 development Methods 0.000 description 3
- 239000000284 extract Substances 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 238000007792 addition Methods 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000002372 labelling Methods 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 239000000725 suspension Substances 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3696—Methods or tools to render software testable
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/18—File system types
- G06F16/1805—Append-only file systems, e.g. using logs or journals to store data
- G06F16/1815—Journaling file systems
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种基于gitlab代码提交日志自动识别差异的方法,包括:为提交日志打上tag标签生成tag版本,设计数据库表记为tag_log表来存储tag版本数据,读取所述tag_log表中构建状态为未构建的所有tag版本列表;调用gitlab服务器的api接口,读取当前tag版本构建结果并写入tag_log表中的构建状态字段;读取tag_log表中未推送状态且构建完成状态的所有tag版本列表;调用gitlab服务器的api接口,读取该tag版本对应分支的最近N条提交记录日志,api接口返回的提交记录日志默认按时间顺序倒序排列;从最近的N条提交记录日志中通过代码提交日志对比算法,识别出tag版本列表中每个版本相对于上个版本所新增的日志列表,将所述日志列表推送至测试平台并将推送结果写入所述tag_log表中。
Description
技术领域
本申请涉及日志处理技术领域,主要涉及一种基于gitlab代码提交日志自动识别差异的方法。
背景技术
在医院信息系统开发过程中,通常用gitlab进行代码管理,系统开发过程中往往涉及到众多业务需求,开发人员通常在gitlab服务器上先创建发布分支,并将开发完成的代码提交到发布分支,同时代码提交记录日志写上本次代码提交的内容。当发布分支完成一定的业务需求开发后,便需要按tag版本命名规则,生成新的tag版本提交测试。测试工程师在对该tag版本进行测试前,往往需要知道该tag版本跟上个tag版本比增加哪些内容,完成哪些需求功能。现有方法主要靠人工将代码修改内容录入测试平台中,非常容易出现录少了或录错了,现有做法存在不能如实体现本次提测的tag版本变更内容,往往给测试带来较大漏测风险,从而降低软件系统的可靠性和稳定性。
发明内容
针对上述现有技术问题,本申请提出了一种基于gitlab代码提交日志自动识别差异的方法。
根据本发明的一方面,提出了一种基于gitlab代码提交日志自动识别差异的方法,包括:
S1、为提交日志打上tag标签,生成tag版本,设计数据库表存储每一个所述tag版本的数据,其中存储的数据包括构建状态和推送状态,所述数据库表记录为tag_log表;
S2、调用gitlab服务器官方提供的api接口,读取所述tag_log表中所有所述tag版本的所述构建状态,如果构建完成,将构建结果写入所述tag_log表中的所述构建状态字段;
S3、读取所述tag_log表中所述推送状态为未推送且所述构建状态为构建完成的所有tag版本列表,选取所述tag版本列表的所有tag版本;
S4、调用gitlab服务器官方提供的api接口,逐个读取所述tag版本列表中每个tag版本对应分支的最近N条提交记录日志,所述最近N条提交记录日志默认按时间顺序倒序排列,获得排序后的最近N条提交记录日志;
S5、从排序后的最近N条提交记录日志中通过代码提交日志对比算法,识别出tag版本列表中每个tag版本相对于上个版本所新增的代码提交记录日志列表,将所述新增的代码提交记录日志列表推送测试平台,并将推送结果写入所述tag_log表中的所述推送状态字段;
其中,所述代码提交日志对比算法具体步骤如下:
定义两个变量,其中一个变量表示第一条提交记录,另一个变量表示最后一条提交记录;
从tag_log表读取所有构建状态为构建完成且推送状态为未推送的tag版本列表;
将所述tag版本列表的列表项的当前提交ID赋值到所述第一条提交记录变量,所述列表项的之前提交ID赋值到所述最后一条提交记录变量;
根据tag版本列表项中的gitlab服务器上的项目代码ID和tag版本分支,调用“GitLab REST API”的/projects/:id/repository/ commits接口,读取所述tag版本列表项对应的最近N条记录列表;
遍历所述最近N条记录列表,其中每个列表项都包括ID值,所述ID值通过commit.getId()方法获得,表示在gitlab上本次代码提交日志的全局唯一值;
通过所述ID进行比对找出新增的列表项,并存入changeList列表中,比对结束后,所述changeList列表的内容即为当前tag版本列表项对应的tag版本所新增的所有代码提交记录日志;
最后将所述changeList列表推送到测试平台,并修改所述tag版本列表项在所述tag_log表中的推送状态改为已推送。
进一步的,所述步骤S1中tag_log表具体还包括:存储每个tag版本的数据时,所述tag_log表中都会增加对应一条记录,如果删除tag版本,则tag数据解析接口会直接从所述tag_log表删除对应的记录。
所述解析出gitlab服务器系统钩子传入的json参数中,能够直接从json参数解析的数据包括:gitlab服务器上的项目代码ID、gitlab服务器上项目代码名称、tag版本分支、tag版本当前的提交ID、tag版本名称、下个tag版本的提交ID;
上个tag版本名称和上个tag版本的提交ID需根据gitlab服务器上的项目代码ID、tag版本分支和tag版本名称从所述tag_log表查询出来。
进一步的,所述gitlab服务器中,所有项目代码都配置对应的CI/CD构建脚本,当在gitlab服务器上打tag标签时,自动调用gitlab runner进行构建编译。
所述步骤S2中调用gitlab服务器官方提供的api接口,具体包括:gitlab服务器的“Gitlab REST API”的/projects/:id/pipelines接口和/projects/:id/pipelines/:pipeline_id/jobs接口。
进一步的,所述步骤S4中调用gitlab服务器官方提供的api接口,具体为gitlab服务器官方提供的“Gitlab REST API”的/projects/:id/ repository/commits接口。
进一步的,所述步骤S1中为提交日志打上tag标签,生成tag版本,其中,为了能准确自动识别每个tag版本,对tag版本名称格式约定了名称取名规范,具体包括:
在master分支编写的tag版本名称格式固定为:release-0.0.x,其中,x从0开始,后继版本号的所述x自动加1;
创建的发布分支名称格式固定为:release-x.x,其中第一个x表示大于0的整数,第二个x表示大于等于0的整数;
在release-x.x分支创建的tag版本号格式为release-x.x.y,其中,y从0开始,每次编写tag版本时,所述y自动加1;
当创建所述release-x.x分支后,需同时创建release-x.x.0的tag版本,作为所述分支的第一个tag版本;
从release-x.x.y tag版本创建的修复分支名称格式为:release-x.x.y -fix,从所述release-x.x.y-fix分支编写的tag名称格式为release-x.x.y.z,其中,z从1开始,后继分支tag版本的所述z自动在原版本上加1。
本申请实施例中的上述一个或多个技术方案,至少具有如下技术效果之一:
1.本发明实现从任意分支上编写符合一定命名规则的tag版本时,如master分支或其它新创建的符合一定命名规则的分支,都能自动从gitlab服务器读取从上个tag版本到当前tag版本的所有代码提交记录日志,并自动将当前tag版本新增的这些代码提交记录日志推送到测试平台。
2.本发明实现在指定的tag版本创建的新的符合一定命名规则的分支打符合一定命名规则的tag版本时,都能自动从gitlab服务器读取从上个tag版本到当前tag版本的所有代码提交记录日志,并自动将当前tag版本新增的这些代码提交记录日志推送到测试平台。
3.本发明实现删除任意的tag版本,重新为提交日志打上tag标签,生成tag版本,能自动从gitlab服务器读取该tag版本对应的上个tag版本到该tag版本的所有代码提交记录日志,并自动将该tag版本新增的这些代码提交记录日志推送到测试平台。
附图说明
包括附图以提供对实施例的进一步理解并且附图被并入本说明书中并且构成本说明书的一部分。附图图示了实施例并且与描述一起用于解释本发明的原理。将容易认识到其它实施例和实施例的很多预期优点,因为通过引用以下详细描述,它们变得被更好地理解。附图的元件不一定是相互按照比例的。同样的附图标记指代对应的类似部件。
图1示出了根据本发明的一个实施例的基于gitlab代码提交日志差异的方法流程示意图;
图2示出了根据本发明的一个具体的实施例的配置系统钩子流程示意图;
图3示出了根据本发明的一个具体的实施例的编辑系统钩子示意图;
图4示出了根据本发明的一个具体的实施例的客户端收到比较结果示意图;
图5示出了根据本发明的一个具体的实施例推送到测试平台收到的数据示意图;
图6示出了根据本发明的一个具体的实施例中测试平台收到代码提交内容示意图。
具体实施方式
下面结合附图和实施例对本申请作进一步的详细说明。可以理解的是,此处所描述的具体实施例仅仅用于解释相关发明,而非对该发明的限定。另外还需要说明的是,为了便于描述,附图中仅示出了与有关发明相关的部分。
需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。
图1示出了根据本发明的一个实施例的基于gitlab代码提交日志差异的方法流程示意图,如图1所示,
步骤S1、为提交日志打上tag标签,生成tag版本,设计数据库表存储每一个所述tag版本的数据,其中存储的数据包括构建状态和推送状态,所述数据库表记录为tag_log表;
这些tag版本列表表示在上个定时任务周期时,这些版本的构建状态是正在构建中,所在本次定时任务执行时,需再次判断这些版本的构建状态。
所述tag_log表具体还包括:存储每个tag版本的数据时,所述tag_log表中都会增加对应一条记录,如果删除tag版本,则tag数据解析接口会直接从所述tag_log表删除对应的记录。
所述存储每个tag版本的数据,所存储的具体数据包括:gitlab服务器上的项目代码ID、gitlab服务器上项目代码名称、推送状态、构建状态、tag版本分支、tag版本当前的提交ID、tag版本名称、下个tag版本的提交ID、上个tag版本名称和上个tag版本的提交ID。
所述数据解析接口具体包括:解析出gitlab服务器系统钩子传入的json参数,将解析结果存入tag_log表中,其中,能够直接从json参数解析的数据包括:
gitlab服务器上的项目代码ID、gitlab服务器上项目代码名称、tag版本分支、tag版本当前的提交ID、tag版本名称、下个tag版本的提交ID;
上个tag版本名称和上个tag版本的提交ID需根据gitlab服务器上的项目代码ID、tag版本分支和tag版本名称从所述tag_log表查询出来。
如图2所示,所述gitlab服务器系统钩子的配置具体步骤包括:
在gitlab服务管理页面,进入“系统钩子”;
URL地址栏输入tag数据解析接口地址;
Secret令牌栏输入gitlab管理员创建的拥有读或写api权限的访问令牌;
触发器选择标签推送事件;
点击“添加系统钩子”按钮。
如图3示出了根据本发明的一个具体的实施例的编辑系统钩子示意图,该示意图呈现了具体的操作界面。
这样就将tag数据解析接口跟gitlab服务器绑定在一起,每次编写tag或删除tag时,gitlab服务器都会回调tag数据解析接口,将tag数据以json格式传入到接口中。
步骤S2、调用gitlab服务器官方提供的api接口,读取所述tag_log表中所有所述tag版本的所述构建状态,如果构建完成,将构建结果写入所述tag_log表中的所述构建状态字段;
所述gitlab服务器中,所有项目代码都配置对应的CI/CD构建脚本,当在gitlab服务器上打tag标签时,自动调用gitlab runner进行构建编译。
所述调用gitlab服务器官方提供的api接口,具体包括:gitlab服务器的“GitlabREST API”的/projects/:id/pipelines接口和/projects/:id /pipelines/:pipe line_id/jobs接口。
所述读取当前tag版本构建结果,具体包括:利用所述api接口返回的数据得到当前tag版本构建结果,如果构建完成,将构建结果写入tag_log表中的构建状态字段,其中,构建结果有6种,分别为:0表示未构建,1表示成功构建,2表示构建失败,3表示挂起,4表示取消,5表示跳过,6表示忽略。
步骤S3、读取所述tag_log表中所述推送状态为未推送且所述构建状态为构建完成的所有tag版本列表,选取所述tag版本列表的所有tag版本;
这次读取的tag版本列表都是版本构建完成,但未将这些版本的日志差异识别出来,下一步就是开始识别这些版本新增的代码日志,看总的新增多少条日志,将版本列表中的每个版本相对于上个版本新增的日志内容提取出来。
步骤S4、调用gitlab服务器官方提供的api接口,逐个读取所述tag版本列表中每个tag版本对应分支的最近N条提交记录日志,所述最近N条提交记录日志默认按时间顺序倒序排列,获得排序后的最近N条提交记录日志;
其中,所述调用gitlab服务器官方提供的api接口,具体为gitlab服务器官方提供的“Gitlab REST API”的/projects/:id/repository/commits接口。
步骤S5、从排序后的最近N条提交记录日志中通过代码提交日志对比算法,识别出tag版本列表中每个tag版本相对于上个版本所新增的代码提交记录日志列表,将所述新增的代码提交记录日志列表推送测试平台,并将推送结果写入所述tag_log表中的所述推送状态字段。
其中,推送状态字段结果状态有4种,具体为:0表示未推送,1表示推送成功,2表示推送失败和3表示忽略;
所述代码提交日志对比算法,算法具体步骤如下:
定义两个变量,其中一个变量表示第一条提交记录,另一个变量表示最后一条提交记录;本实施例中,定义第一条提交记录变量为String startSha,定义最后一条提交记录变量为String endSha。
从tag_log表读取所有构建状态为构建完成且推送状态为未推送的tag版本列表;
将所述tag版本列表的列表项的当前提交ID赋值到所述第一条提交记录变量,所述列表项的之前提交ID赋值到所述最后一条提交记录变量;
根据tag版本列表项中的gitlab服务器上的所述项目代码ID和所述tag版本分支,调用“GitLab REST API”的/projects/:id/repository/ commits接口,读取所述tag版本列表项对应的最近N条记录列表;
遍历所述最近N条记录列表,其中每个列表项都包括ID值,所述ID值通过commit.getId()方法获得,表示在gitlab上本次代码提交日志的全局唯一值;
通过所述ID进行比对找出新增的列表项,并存入changeList列表中,比对结束后,所述changeList列表的内容即为当前tag版本列表项对应的tag版本所新增的所有代码提交记录日志;
最后将所述changeList列表推送到测试平台,并修改所述tag版本列表项在所述tag_log表中的推送状态为已推送。
本实施例中,算法核心代码如下:
// 存储当前tag版本新增的代码提交记录日志
List<String> changeList = new ArrayList<>();
// 标记开始从最近N条记录列表中读取列表项位置
boolean addFlage = false;
for (Commit commit : commitList) {
//该条提交记录要推给测试平台
if (commit.getId().equals(startSha)) {
addFlage = true;
}
//该条提交记录上次已推送过,所以这次无需推给测试平台,
if (commit.getId().equals(endSha)) {
addFlage = false;
break;
}
//开始存储该tag版本新增的提交记录
/if(addFlage == true) {
changeList.add(commit.getTitle());
}
}
为了能准确自动识别每个tag版本,对tag版本名称格式约定了名称取名规范,具体包括:
在master分支编写的tag版本名称格式固定为:release-0.0.x,其中,x从0开始,后继版本号的所述x自动加1;
创建的发布分支名称格式固定为:release-x.x,其中第一个x表示大于0的整数,第二个x表示大于等于0的整数;
在release-x.x分支创建的tag版本号格式为release-x.x.y,其中,y从0开始,每次编写tag版本时,所述y自动加1;
当创建所述release-x.x分支后,需同时创建release-x.x.0的tag版本,作为所述分支的第一个tag版本;
从release-x.x.y tag版本创建的修复分支名称格式为:release-x.x.y -fix,从所述release-x.x.y-fix分支编写的tag名称格式为release-x.x.y.z,其中,z从1开始,后继分支tag版本的所述z自动在原版本上加1。
本实施例中,
如图4示出了根据本发明的一个具体的实施例的客户端收到比较结果示意图,编译tag为release-0.0.51,提取出的对比差异有3条,并送至测试端及时测试。
如图5示出了根据本发明的一个具体的实施例推送到测试平台收到的数据示意图,测试平台可以收到编译tag为release-0.0.51的3条对比差异数据。
如图6示出了根据本发明的一个具体的实施例中测试平台收到代码提交内容示意图,测试平台可以直观的看出对比过后的日志差异内容。
定时任务每15秒执行一次,进行检查构建状态,同时进行tag版本新增日志比较并推送到测试平台。
本发明实现从任意分支上打符合一定命名规则的tag版本时,如master分支或其它新创建的符合一定命名规则的分支,都能自动从gitlab服务器读取从上个tag版本到当前tag版本的所有代码提交记录日志,并自动将当前tag版本新增的这些代码提交记录日志推送到测试平台。
本发明实现在指定的tag版本创建的新的符合一定命名规则的分支打符合一定命名规则的tag版本时,都能自动从gitlab服务器读取从上个tag版本到当前tag版本的所有代码提交记录日志,并自动将当前tag版本新增的这些代码提交记录日志推送到测试平台。
本发明实现删除任意的tag版本,重新打个相同名称的tag版本,能自动从gitlab服务器读取该tag版本对应的上个tag版本到该tag版本的所有代码提交记录日志,并自动将该tag版本新增的这些代码提交记录日志推送到测试平台。
综上,通过本发明实现了自动读取gitlab服务器上从上个tag版本到当前tag版本的所有新增代码提交记录日志,并自动将这些提交记录日志推送给测试平台。由于这些新增代码提交记录日志都由程序计算生成,无人为干预,所以不存在人为录少或录错问题,测试工程师根据该提交记录日志对软件进行测试,大大降低了漏测风险,从而提高软件系统的可靠性和稳定性。
附图中的流程图和框图,图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分,该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个接连地表示的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合,可以用执行规定的功能或操作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。
描述于本申请实施例中所涉及到的模块可以通过软件的方式实现,也可以通过硬件的方式来实现。
以上描述仅为本申请的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解,本申请中所涉及的发明范围,并不限于上述技术特征的特定组合而成的技术方案,同时也应涵盖在不脱离上述发明构思的情况下,由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本申请中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。
Claims (9)
1.一种基于gitlab代码提交日志自动识别差异的方法,其特征在于,包括以下步骤:
S1、为提交日志打上tag标签,生成tag版本,设计数据库表存储每一个所述tag版本的数据,其中存储的数据包括构建状态和推送状态,所述数据库表记录为tag_log表;
S2、调用gitlab服务器官方提供的api接口,读取所述tag_log表中所有所述tag版本的所述构建状态,如果构建完成,将构建结果写入所述tag_log表中的所述构建状态字段;
S3、读取所述tag_log表中所述推送状态为未推送且所述构建状态为构建完成的所有tag版本列表,选取所述tag版本列表的所有tag版本;
S4、调用gitlab服务器官方提供的api接口,逐个读取所述tag版本列表中每个tag版本对应分支的最近N条提交记录日志,所述最近N条提交记录日志默认按时间顺序倒序排列,获得排序后的最近N条提交记录日志;
S5、从排序后的最近N条提交记录日志中通过代码提交日志对比算法,识别出tag版本列表中每个tag版本相对于上个版本所新增的代码提交记录日志列表,将所述新增的代码提交记录日志列表推送测试平台,并将推送结果写入所述tag_log表中的所述推送状态字段;
其中,所述代码提交日志对比算法具体步骤如下:
定义两个变量,其中一个变量表示第一条提交记录,另一个变量表示最后一条提交记录;
从tag_log表读取所有构建状态为构建完成且推送状态为未推送的tag版本列表;
将所述tag版本列表的列表项的当前提交ID赋值到所述第一条提交记录变量,所述列表项的之前提交ID赋值到所述最后一条提交记录变量;
根据tag版本列表项中的gitlab服务器上的项目代码ID和tag版本分支,调用“GitLabREST API”的/projects/:id/repository/ commits接口,读取所述tag版本列表项对应的最近N条记录列表;
遍历所述最近N条记录列表,其中每个列表项都包括ID值,所述ID值通过commit.getId()方法获得,表示在gitlab上本次代码提交日志的全局唯一值;
通过所述ID进行比对找出新增的列表项,并存入changeList列表中,比对结束后,所述changeList列表的内容即为当前tag版本列表项对应的tag版本所新增的所有代码提交记录日志;
最后将所述changeList列表推送到测试平台,并修改所述tag版本列表项在所述tag_log表中的推送状态改为已推送。
2.根据权利要求1所述的方法,其特征在于:所述步骤S1中tag_log表具体还包括:存储每个tag版本的数据时,所述tag_log表中都会增加对应一条记录,如果删除tag版本,则tag数据解析接口会直接从所述tag_log表删除对应的记录。
3.根据权利要求2所述的方法,其特征在于:所述数据解析接口具体包括:解析出gitlab服务器系统钩子传入的json参数,将解析结果存入tag_log表中。
4.根据权利要求3所述的方法,其特征在于:所述解析出gitlab服务器系统钩子传入的json参数中,能够直接从json参数解析的数据包括:gitlab服务器上的项目代码ID、gitlab服务器上项目代码名称、tag版本分支、tag版本当前的提交ID、tag版本名称、下个tag版本的提交ID;
上个tag版本名称和上个tag版本的提交ID需根据gitlab服务器上的项目代码ID、tag版本分支和tag版本名称从所述tag_log表查询出来。
5.根据权利要求1所述的方法,其特征在于:所述gitlab服务器中,所有项目代码都配置对应的CI/CD构建脚本,当在gitlab服务器上打tag标签时,自动调用gitlab runner进行构建编译。
6.根据权利要求1所述的方法,其特征在于:所述步骤S2中调用gitlab服务器官方提供的api接口,具体包括:gitlab服务器的“Gitlab REST API”的/projects/:id/pipelines接口和/projects/:id/pipelines/:pipe line_id/jobs接口。
7.根据权利要求1所述的方法,其特征在于:所述步骤S4中调用gitlab服务器官方提供的api接口,具体为gitlab服务器官方提供的“Gitlab REST API”的/projects/:id/repository/commits接口。
8.根据权利要求1所述的方法,其特征在于:所述步骤S1中为提交日志打上tag标签,生成tag版本,其中,为了能准确自动识别每个tag版本,对tag版本名称格式约定了名称取名规范,具体包括:
在master分支编写的tag版本名称格式固定为:release-0.0.x,其中,x从0开始,后继版本号的所述x自动加1;
创建的发布分支名称格式固定为:release-x.x,其中第一个x表示大于0的整数,第二个x表示大于等于0的整数;
在release-x.x分支创建的tag版本号格式为release-x.x.y,其中,y从0开始,每次编写tag版本时,所述y自动加1;
当创建所述release-x.x分支后,需同时创建release-x.x.0的tag版本,作为所述分支的第一个tag版本;
从release-x.x.y tag版本创建的修复分支名称格式为:release-x.x.y -fix,从所述release-x.x.y-fix分支编写的tag名称格式为release-x.x.y.z,其中,z从1开始,后继分支tag版本的所述z自动在原版本上加1。
9.一种计算机可读介质,其上存储有计算机程序,所述计算机程序在被处理器执行时实施如权利要求1-8中任一项所述的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202410055725.4A CN117573564B (zh) | 2024-01-15 | 2024-01-15 | 一种基于gitlab代码提交日志自动识别差异的方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202410055725.4A CN117573564B (zh) | 2024-01-15 | 2024-01-15 | 一种基于gitlab代码提交日志自动识别差异的方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN117573564A CN117573564A (zh) | 2024-02-20 |
CN117573564B true CN117573564B (zh) | 2024-03-26 |
Family
ID=89886554
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202410055725.4A Active CN117573564B (zh) | 2024-01-15 | 2024-01-15 | 一种基于gitlab代码提交日志自动识别差异的方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN117573564B (zh) |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103092761A (zh) * | 2013-02-05 | 2013-05-08 | 烽火通信科技股份有限公司 | 基于差异信息文件识别和检查修改代码块的方法及装置 |
CN106462586A (zh) * | 2014-03-28 | 2017-02-22 | 华为技术有限公司 | 基于记录的多版本并发控制的一致性读取的有效方法和系统 |
CN109144548A (zh) * | 2018-08-27 | 2019-01-04 | 杭州安恒信息技术股份有限公司 | 一种基于git实现的多组件软件升级方法、装置及服务器 |
WO2020253082A1 (zh) * | 2019-06-18 | 2020-12-24 | 平安科技(深圳)有限公司 | 处理svn日志文件的方法、装置、设备及存储介质 |
CN114637688A (zh) * | 2022-04-07 | 2022-06-17 | 中国工商银行股份有限公司 | 基于版本分支的覆盖率统计方法及装置 |
CN115269444A (zh) * | 2022-09-30 | 2022-11-01 | 平安银行股份有限公司 | 代码静态检测方法、装置及服务器 |
-
2024
- 2024-01-15 CN CN202410055725.4A patent/CN117573564B/zh active Active
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103092761A (zh) * | 2013-02-05 | 2013-05-08 | 烽火通信科技股份有限公司 | 基于差异信息文件识别和检查修改代码块的方法及装置 |
CN106462586A (zh) * | 2014-03-28 | 2017-02-22 | 华为技术有限公司 | 基于记录的多版本并发控制的一致性读取的有效方法和系统 |
CN109144548A (zh) * | 2018-08-27 | 2019-01-04 | 杭州安恒信息技术股份有限公司 | 一种基于git实现的多组件软件升级方法、装置及服务器 |
WO2020253082A1 (zh) * | 2019-06-18 | 2020-12-24 | 平安科技(深圳)有限公司 | 处理svn日志文件的方法、装置、设备及存储介质 |
CN114637688A (zh) * | 2022-04-07 | 2022-06-17 | 中国工商银行股份有限公司 | 基于版本分支的覆盖率统计方法及装置 |
CN115269444A (zh) * | 2022-09-30 | 2022-11-01 | 平安银行股份有限公司 | 代码静态检测方法、装置及服务器 |
Also Published As
Publication number | Publication date |
---|---|
CN117573564A (zh) | 2024-02-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10621212B2 (en) | Language tag management on international data storage | |
US6182245B1 (en) | Software test case client/server system and method | |
US7577946B2 (en) | Program product, method, and system for testing consistency of machine code files and source files | |
RU2210803C2 (ru) | Компьютерное устройство для выполнения прикладных программ | |
US9207933B2 (en) | Identifying authors of changes between multiple versions of a file | |
US20130290937A1 (en) | Efficient extraction of software dependencies from program code | |
CN111694612A (zh) | 配置检查方法、装置、计算机系统及存储介质 | |
CN117112060A (zh) | 组件库构建方法、装置、电子设备及存储介质 | |
US20080022263A1 (en) | Identifying The Origin Of Application Resources | |
JP2016045545A (ja) | 影響調査システム、影響調査方法、および影響調査プログラム | |
CN111796855A (zh) | 一种增量版本更新方法、装置、存储介质及计算机设备 | |
US10678864B2 (en) | Analysis model preparing system, programming apparatus, and analysis model preparing method | |
CN110990055A (zh) | 一种基于程序分析的Pull Request功能分类方法 | |
CN116088846A (zh) | 一种持续集成代码格式的处理方法、相关装置及设备 | |
CN117573564B (zh) | 一种基于gitlab代码提交日志自动识别差异的方法 | |
JP6336919B2 (ja) | ソースコードレビュー方法及びそのシステム | |
US20070162259A1 (en) | Method for converting a log of user manipulations of a computer program into task documentation | |
CN115455059A (zh) | 一种基于底层数据解析用户行为的方法、装置及相关介质 | |
CN112256365B (zh) | 一种自动化管理多语言版本的方法及终端 | |
CN113504904A (zh) | 用户定义函数实现方法、装置、计算机设备和存储介质 | |
JPH09258975A (ja) | アプリケーションプログラムの構成作成支援方法 | |
JP3464159B2 (ja) | テスト仕様書作成装置およびそのプログラムを格納した記憶媒体 | |
US6782523B2 (en) | Parallel configurable IP design methodology | |
Rose et al. | Concordance: A framework for managing model integrity | |
CN117687681B (zh) | 一种低代码应用的版本管理方法及系统 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |