一种识别配方文件并转化为XML文件的方法及系统
技术领域
本发明涉及计算机应用技术领域,特别涉及一种识别配方文件并转化为XML文件的方法及系统。
背景技术
在互联网的软件开发与发布过程中,持续集成是一个重要的过程,持续集成是指持续性地将代码集成到主干分支,继而实现持续性构建与自动化测试。这样快速的迭代可以快速的发现并解决bug,保证代码的质量。
在软件开发过程中,源代码的管理是一个极其重要的环节。一个项目的源代码往往是随着开发进度在持续变化的,为了保留代码的所有修订版本,用户可以采取复制整个项目的目录并改名加上备注时间等依次保留项目的所有修订版本,但这无疑是不严谨的,且无法真正做到版本控制,比如在存储过程中一不小心写错了文件名,或是覆盖了其他已存在的文件版本,这将会导致以前版本的丢失,甚至对整个项目都造成致命的影响。于是版本控制的概念应运而生,版本控制系统记录了所有文件每次变更的差异,保证可以准确的回溯到之前的任意一个版本。Git作为分布式版本控制系统已成为当代源代码管理的主流,因其分布式的特性使得每一次克隆操作都是对代码仓库的完成备份,即便服务器发生故障,也可以使用客户端代码最大限度的恢复服务器仓库。
在软件持续集成过程中,源代码仓库的配置与管理可以采用多种形式,当前比较流行的主要有三种:第一种是使用YAML文件的Recipe仓库,主要使用Bob工具进行源代码的检出及构建;第二种是使用BB类型文件的Yocto仓库,主要使用Bitbake工具进行源代码的检出与构建;第三种是使用XML类型文件的Manifest仓库,主要使用Repo工具进行源代码的管理。其中Recipe仓库与Yocto仓库均可以理解为一个食谱,该食谱中包含各种食物的做法,即,软件项目中的各个模块的构建方法。YAML类型文件和BB类型文件都可以称为配方文件,一个配方文件即对应软件项目中一个最小构建单元模块,最小构建单元模块是构成一个功能模块的基本单元,为了更好的组织目录结构,属于同一个功能模块的配方文件通常放置在该功能模块的子目录中。配方文件主要包含三个部分:源代码检出、编译方法和打包方法;其中源代码检出部分包含该模块所使用的Git仓库的基本信息,包括该仓库的链接以及分支等。对于Recipe仓库来说,所有的配方文件都存放在recipes/目录中,且均为YAML类型文件,Bob工具依据recipes/目录内的YAML文件来实现整个项目的自动构建框架。而对于Yocto仓库来说,所有的配方文件都存放在Metadata元数据集中的以recipes-开头的相应模块的目录中,且均为BB类型的配方文件,Bitbake工具则是依据配方文件来实现项目构建的。而Manifest仓库主要应用于Android源码管理,由于Android源代码工程是一个大型的开源工程,通常所用的Git源代码版本管理工具已经不能满足需求,于是Repo工具应运而生,Repo对Git进行了封装,可以对整个Android工程的所有源代码仓库进行批量操作。Manifest仓库使用一个XML文件存放Android项目所有子项目的Git仓库元信息,Repo工具则通过这个Manifest仓库实现对所有源代码的管理与操作。
XML是一种可扩展元标记语言,开发者可以根据自身需要定义自己的标记。而YAML是一种以数据为中心的语言。YAML更简单,且可读性高,易于实现。故实际应用中YAML更主流一些。而BB文件则是Yocto项目中使用的专有配方文件。但是在持续集成领域的源代码管理过程中,往往有时用户只想提取项目中源代码的相关信息,而无论源代码仓库是使用Recipe仓库的形式还是使用Yocto仓库的形式,用户都必须依次读取各个配方文件才能获取到所有源代码仓库的信息,非常耗时且繁琐,并且也无法同时对这些源代码仓库进行批量操作。
发明内容
针对上述现有技术中存在的问题,本发明提供了一种识别配方文件并转化为XML文件的方法及系统。本发明实施例提供的技术方案具体如下:
第一方面,提供了一种识别配方文件并转化为XML文件的方法,所述方法包括:
对克隆到本地仓库中的所有配方文件的文件类型进行识别,判断其为YAML类型文件还是BB类型文件;
根据所述识别的结果,调用相应的预设脚本以执行如下操作:
对所有所述配方文件进行解析,生成包含所有源代码仓库的信息的JSON文件;
对所述JSON文件进行解析,提取出各所述源代码仓库的链接、索引及存储路径;
将提取到的各所述源代码仓库的链接、索引及存储路径按键值对写入对应的字典中;
从所有所述字典中识别出各所述源代码仓库的链接、索引及存储路径,并写入Manifest仓库的XML文件中。
进一步地,所述预设脚本为Python脚本或Shell脚本。
进一步地,所述源代码仓库的索引为仓库分支名、仓库commit号和仓库tag号中的任意一个。
进一步地,所述字典中包含第一键值对和第二键值对,所述将提取到的各所述源代码仓库的链接、索引及存储路径按键值对写入对应的字典中,包括:
根据各所述源代码仓库的索引对所有所述源代码仓库进行分类,得到各所述源代码仓库的类别值;
以各所述源代码仓库的类别值作为所述第一键值对的键,以所述第二键值对作为所述第一键值对的值;
其中,所述第二键值对的键为各所述源代码仓库的链接,所述第二键值对的值为各所述源代码仓库的链接对应的索引以及存储路径。
进一步地,所述从所有所述字典中识别出各所述源代码仓库的链接、索引及存储路径,并写入Manifest仓库的XML文件中,包括:
在本地创建所述XML文件;
根据所述字典中的键值对,识别出各所述源代码仓库的链接、索引及存储路径;
将各所述源代码仓库的链接、索引及存储路径分别作为属性值写入所述XML文件中;
将所述XML文件上传至所述Manifest仓库中。
第二方面,提供了一种识别配方文件并转化为XML文件的系统,所述系统包括:
类型识别模块,用于对克隆到本地仓库中的所有配方文件的文件类型进行识别,判断其为YAML类型文件还是BB类型文件;
脚本调用模块,用于根据所述识别的结果,调用相应的预设脚本对所有所述配方文件进行处理;
脚本运行模块,用于运行所述预设脚本以执行如下操作:
对所有所述配方文件进行解析,生成包含所有源代码仓库的信息的JSON文件;
对所述JSON文件进行解析,提取出各所述源代码仓库的链接、索引及存储路径;
将提取到的各所述源代码仓库的链接、索引及存储路径按键值对写入对应的字典中;
从所有所述字典中识别出各所述源代码仓库的链接、索引及存储路径,并写入Manifest仓库的XML文件中。
进一步地,所述预设脚本为Python脚本或Shell脚本。
进一步地,所述源代码仓库的索引为仓库分支名、仓库commit号和仓库tag号中的任意一个。
进一步地,所述字典中包含第一键值对和第二键值对,所述脚本运行模块具体用于:
运行所述预设脚本以执行如下操作:
根据各所述源代码仓库的索引对所有所述源代码仓库进行分类,得到各所述源代码仓库的类别值;
以各所述源代码仓库的类别值作为所述第一键值对的键,以所述第二键值对作为所述第一键值对的值;
其中,所述第二键值对的键为各所述源代码仓库的链接,所述第二键值对的值为各所述源代码仓库的链接对应的索引以及存储路径。
进一步地,所述脚本运行模块具体还用于:
运行所述预设脚本以执行如下操作:
在本地创建所述XML文件;
根据所有所述字典中的键值对,识别出各所述源代码仓库的链接、索引及存储路径;
将各所述源代码仓库的链接、索引及存储路径分别作为属性值写入所述XML文件中,并将所述XML文件上传至所述Manifest仓库中。
本发明实施例提供了一种识别配方文件并转化为XML文件的方法及系统,首先对克隆到本地仓库中的所有配方文件是YAML类型文件还是BB类型文件进行识别,根据识别的结果,调用相应的预设脚本以执行如下操作:对所有配方文件进行解析,生成包含所有源代码仓库的信息的JSON文件,然后对JSON文件进行解析,提取出各源代码仓库的链接、索引及存储路径,并将提取到的各源代码仓库的链接、索引及存储路径按键值对写入对应的字典中,以及从所有字典中识别出各源代码仓库的链接、索引及存储路径,并写入Manifest仓库的XML文件中,如此可以使得在持续集成领域的源代码管理过程中,当用户只想提取项目中源代码的相关信息时,无论源代码仓库的配置与管理是使用Recipe仓库还是使用Yocto仓库的形式,用户都无需再依次读取仓库中的各个配方文件才能获取到所有源代码仓库的信息,而只需从转化得到的XML文件中读取源代码仓库的信息即可,方便了用户读取源代码仓库的相关信息;并且,通过转化得到Manifest仓库的XML文件,可以实现对源代码仓库进行批量操作,从而使得对持续集成领域的源代码管理更加高效便捷。
附图说明
为了更清楚地说明本发明实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本发明实施例提供的识别配方文件并转化为XML文件的方法的流程图;
图2为本发明实施例提供的文件转化流程的示意图;
图3为本发明实施例提供的识别配方文件并转化为XML文件的系统的结构框图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
需要说明的是,在本发明的描述中,术语“第一”、“第二”等仅用于描述目的,而不能理解为指示或暗示相对重要性。此外,在本发明的描述中,除非另有说明,“多个”的含义是两个或两个以上。
除非上下文明确要求,否则整个说明书和权利要求书中的“包括”、“包含”等类似词语应当解释为包含的含义而不是排他或穷举的含义;也就是说,是“包括但不限于”的含义。例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
本发明实施例提供的一种识别配方文件并转化为XML文件的方法,可应用于持续集成领域的源代码管理过程中对源代码相关信息进行获取的场景,该方法能够实现识别克隆到本地仓库的所有配方文件并转化为Manifest仓库的XML文件,该方法可以由识别配方文件并转化为XML文件的系统来执行,该系统可以采用软件和/或硬件的方式实现,该系统可以集成在任何具有网络通信功能的计算机设备中,该计算机设备具体可以是个人计算机。
图1为本发明实施例提供的识别配方文件并转化为XML文件的方法的流程图,如图1所示,该方法可以包括步骤:
101、对克隆到本地仓库中的所有配方文件的文件类型进行识别,判断其为YAML类型文件还是BB类型文件。
其中,当本地仓库为Recipe仓库时,配方文件的类型为YAML文件类型,当本地仓库为Yocto仓库时,配方文件的类型为BB文件类型。
具体地,可以根据配方文件的文件名后缀识别配方文件是YAML类型文件还是BB类型文件。配方文件的文件名后缀为.yaml时,配方文件是YAML类型文件,配方文件的文件名后缀为.bb时,配方文件是BB类型文件。
在具体实现过程中,可以通过编写Python脚本或Shell脚本,脚本通过读取配方文件的文件后缀名,识别配方文件是YAML类型文件还是BB类型文件。
进一步地,在步骤101之前,本发明实施例提供的方法还可以包括:
对远程服务器上的Recipe仓库或者Yocto仓库进行仓库克隆,得到本地仓库。
具体地,使用git clone命令对远程服务器上的Recipe仓库进行仓库克隆,得到本地的Recipe仓库,该Recipe仓库使用YAML文件格式存储各个Git仓库的配置信息,其中,各个Git仓库的配置信息保存在Recipe仓库中各个YAML文件的checkoutSCM部分中。此外,需要说明的是,Recipe仓库的各个YAML文件中除了Git仓库的配置信息外,还包含编译、打包等信息。或者,可以使用git clone命令对远程服务器上的Yocto仓库进行仓库克隆,得到本地的Yocto仓库,Yocto仓库使用BB文件格式存储各个Git仓库的配置信息,其中BB文件存储各个Git仓库配置信息,保存在文件中的SRC_URI字段中,且标明“protocol=git”参数。
其中,Git是LinusTorvalds为了帮助管理Linux内核开发而开发的一个开放源码的版本控制软件。Git支持从服务器上克隆完整的Git仓库(包括代码和版本信息)到单机上。
102、根据识别的结果,调用相应的预设脚本以执行如下操作:对所有配方文件进行解析,生成包含所有源代码仓库的信息的JSON文件,对JSON文件进行解析,提取出各源代码仓库的链接、索引及存储路径,将提取到的各源代码仓库的链接、索引及存储路径按键值对写入对应的字典中,从所有字典中识别出各源代码仓库的链接、索引及存储路径,并写入Manifest仓库的XML文件中。
其中,配方文件是YAML类型文件,则调用YAML类型文件对应的第一预设脚本对所有配方文件进行处理,配方文件是BB类型文件,则调用BB类型文件对应的第二预设脚本对所有配方文件进行处理。其中,第一预设脚本和第二预设脚本均预先存储在本地数据库中。
这里,第一预设脚本和第二预设脚本均可以为Python脚本,Python是一种机器语言,可以用于从所有配方文件中解析出所有源代码仓库的信息,此外,第一预设脚本和第二预设脚本还可以为Shell脚本。
进一步地,步骤102中对所有所述配方文件进行解析,生成包含所有源代码仓库的信息的JSON文件,可以包括:
配方文件是YAML类型文件时,YAML类型文件对应的Python脚本可以使用bobproject命令解析Recipe仓库中的所有YAML文件,识别成一个JSON文件,该JSON文件包含所有源代码仓库的信息,其中,JSON (JavaScript Object Notation)是一种轻量级的数据交换格式,源代码仓库的信息包括源代码仓库的链接、索引及存储路径。配方文件是BB类型文件时,BB类型文件对应的Python脚本可以直接使用Python语言识别各个BB文件,生成相应的JSON文件。
进一步地,步骤102中对所述JSON文件进行解析,提取出各所述源代码仓库的链接、索引及存储路径,可以包括:
调用Python脚本读取JSON文件,从JSON文件中提取出各所述源代码仓库的链接、索引及存储路径。
其中,源代码仓库的链接具体可以是源代码仓库的名称。
其中,源代码仓库的索引为源代码仓库的分支名(branch名)、commit号和tag号中的任意一个。commit号的优先级高于tag号,tag号的优先级高于分支名。
进一步地,所述字典中包含第一键值对和第二键值对,字典可以为Python字典,步骤102中将提取到的各所述源代码仓库的链接、索引及存储路径按键值对写入对应的字典中,可以包括:
根据各所述源代码仓库的索引对所有所述源代码仓库进行分类,得到各所述源代码仓库的类别值;
以各所述源代码仓库的类别值作为所述第一键值对的键,以所述第二键值对作为所述第一键值对的值;
其中,所述第二键值对的键为各所述源代码仓库的链接,所述第二键值对的值为各所述源代码仓库的链接对应的索引以及存储路径。
在具体实施过程中,可以根据源代码仓库实际使用的索引,将所有源代码仓库分为三类,分别为:branch、tag、commit。在写入Python字典的过程中,以这三个类别值分别作为键,该键对应的值也是一个键值对,该键值对的键为源代码仓库的链接,值为源代码仓库的链接对应的索引以及存储路径,这样可以分别生成branch、tag、commit各自对应的字典,根据新生成的字典可以分别获取每个源代码仓库实际使用的索引,其中,当索引为tag时,需要使用revision="refs/tags/tag名"的形式。
进一步地,步骤102中从所有所述字典中识别出各所述源代码仓库的链接、索引及存储路径,并写入Manifest仓库的XML文件中,可以包括:
在本地创建所述XML文件,根据所述字典中的键值对,识别出各所述源代码仓库的链接、索引及存储路径,并将各所述源代码仓库的链接、索引及存储路径分别作为属性值写入所述XML文件中,以及将所述XML文件上传至所述Manifest仓库中。
其中,本地创建的XML文件主要包括三个部分:remote、default、project。
Remote部分用来指定远程仓库信息,包含fetch,name,review三个字段。fetch代表Git仓库存储地址前缀,review代表代码审核服务器链接,name代表远程Git服务器名,一般与Git默认名保持一致,即为“origin”。
Default部分设定所有project的默认待写入属性的值,一般包含三个字段:remote,revision,sync_j。其中remote属性选择在remote部分定义的多个name中的一个作为默认的远程Git服务器名,如project中部分仓库不使用这个远程服务器,则需要额外使用remote字段指定。Revision属性表示默认使用的git索引,该索引可以为分支,commit或者tag,当使用tag作为索引时,其写法应为revision="refs/tags/tag名"。sync_j代表在repo sync中默认并行下载的仓库数目,可以依实际服务器性能而定。
Project部分指定具体需要克隆的Git仓库。一般包含三个字段:name,path,revision。其中name代表Git仓库的唯一标识,与remote中定义的fetch结合生成该Git仓库的实际地址。Path代表将Git仓库拉取到本地之后的存储路径,若没有指定,则使用name名作为目录名。Revision代表需要拉取的Git仓库的索引,可以为commit、tag或分支,若没有指定,则使用default部分设置的默认revision作为当前project的revision。
本实施例中,根据获取到的Python字典(即commit对应的字典、tag对应的字典以及branch对应的字典),分别识别其中的仓库链接,获取远程仓库的地址,即remote部分中的fetch属性,review属性与fetch属性保持一致,其他字段均使用默认值;根据远程仓库的地址先将本地创建的xml文件中的remote与default部分写入;然后根据Python字典识别每个Git仓库的name、path、revision,依次写入XML文件中的project部分。这样就生成了一个包含所有源代码仓库信息的XML文件,最后将该XML文件上传到一个Manifest仓库中。
进一步地,在步骤102之后,本发明实施例提供的方法还可以包括:
根据Manifest仓库的XML文件,对所有源代码仓库进行批量操作。
其中,批量操作包括但不限于下载所有的源代码仓库、为所有的源代码仓库创建新的分支、将创建的分支推送到服务端、获取所有源代码仓库的提交历史。
具体地,使用repo init–u命令初始化,然后使用repo sync命令可以一键下载所有的源代码仓库;使用“repo forall–p–c git checkout–b:new_branch”为所有的仓库创建新的分支,同时也可以把该分支推送到服务器端,即执行“repo forall–p–c git pushorigin new_branch:new_branch”。使用“repo forall -p -c git log --pretty=oneline--abbrev-commit --graph --since=1days”获取一段时间内所有仓库的提交历史,由此实现了无法通过使用Recipe仓库的形式及Yocto仓库的形式实现的批量操作。
图2为本发明实施例提供的文件转化流程的示意图。在图2中,无论是使用YAML类型文件作为配方文件的Recipe仓库,还是BB类型文件作为配方文件的Yocto仓库,用户需要依次对各个源代码仓库进行操作,而通过本发明实施例提供的方法对上述的两种类型的配方文件进行识别并转换成Manifest仓库的XML文件后,可根据Manifest仓库的XML文件,使用一个命令同时对多个源代码仓库进行批量操作,这样对源代码的管理更加高效便捷。
本发明实施例提供了一种识别配方文件并转化为XML文件的方法,首先对克隆到本地仓库中的所有配方文件的文件类型进行识别,判断其为YAML类型文件还是BB类型文件,根据识别的结果,调用相应的预设脚本以执行如下操作:对所有配方文件进行解析,生成包含所有源代码仓库的信息的JSON文件,然后对JSON文件进行解析,提取出各源代码仓库的链接、索引及存储路径,并将提取到的各源代码仓库的链接、索引及存储路径按键值对写入对应的字典中,最后从所有字典中识别出各所述源代码仓库的链接、索引及存储路径,并写入Manifest仓库的XML文件中,如此可以使得在持续集成领域的源代码管理过程中,当用户只想提取项目中源代码的相关信息时,无论源代码仓库的配置与管理是使用Recipe仓库还是使用Yocto仓库的形式,用户都无需再依次读取各个配方文件才能获取到所有源代码仓库的信息,而只需从转化得到的XML文件中读取源代码仓库的信息即可,方便了用户读取源代码仓库的相关信息;并且,通过转化得到Manifest仓库的XML文件,可以实现对源代码仓库进行批量操作,从而使得对持续集成领域的源代码管理更加高效便捷。
图3为本发明实施例提供的识别配方文件并转化为XML文件的系统的结构框图,如图3所示,所述系统可以包括:
类型识别模块31,用于对克隆到本地仓库中的所有配方文件的文件类型进行识别,判断其为YAML类型文件还是BB类型文件;
脚本调用模块32,用于根据所述识别的结果,调用相应的预设脚本对所有所述配方文件进行处理;
脚本运行模块33,用于运行所述预设脚本以执行如下操作:
对所有所述配方文件进行解析,生成包含所有源代码仓库的信息的JSON文件;
对所述JSON文件进行解析,提取出各所述源代码仓库的链接、索引及存储路径;
将提取到的各所述源代码仓库的链接、索引及存储路径按键值对写入对应的字典中;
从所有所述字典中识别出各所述源代码仓库的链接、索引及存储路径,并写入Manifest仓库的XML文件中。
进一步地,所述预设脚本为Python脚本或Shell脚本。
进一步地,所述源代码仓库的索引为仓库分支名、仓库commit号和仓库tag号中的任意一个。
进一步地,所述字典中包含第一键值对和第二键值对,所述脚本运行模块33具体用于:
运行所述预设脚本以执行如下操作:
根据各所述源代码仓库的索引对所有所述源代码仓库进行分类,得到各所述源代码仓库的类别值;
将各所述源代码仓库的类别值作为所述第一键值对的键,以所述第二键值对作为所述第一键值对的值;
其中,所述第二键值对的键为各所述源代码仓库的类别值对应的所述源代码仓库链接,所述第二键值对的值为所述源代码仓库链接对应的源代码仓库索引以及源代码仓库存储路径。
进一步地,所述脚本运行模块33具体还用于:
运行所述预设脚本以执行如下操作:
在本地创建所述XML文件;
根据所有所述字典中的键值对,识别出各所述源代码仓库的链接、索引及存储路径;
将各所述源代码仓库的链接、索引及存储路径分别作为属性值写入所述XML文件中,并将所述XML文件上传至所述Manifest仓库中。
本实施例提供的识别配方文件并转化为XML文件的系统,与本发明实施例所提供的识别配方文件并转化为XML文件的方法属于同一发明构思,可执行本发明任意实施例所提供的识别YAML文件并转化为XML文件的方法,具备执行用于识别配方文件并转化为XML文件的方法相应的功能模块和有益效果。未在本实施例中详尽描述的技术细节,可参见本发明实施例提供的识别配方文件并转化为XML文件的方法,此处不再加以赘述。
上述所有可选技术方案,可以采用任意结合形成本发明的可选实施例,在此不再一一赘述。
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成,也可以通过程序来指令相关的硬件完成,程序可以存储于一种计算机可读存储介质中,上述提到的存储介质可以是只读存储器,磁盘或光盘等。
以上仅为本发明的较佳实施例,并不用以限制本发明,凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。