CN107391968B - 一种实现私有pod发布权限控制的方法及装置 - Google Patents
一种实现私有pod发布权限控制的方法及装置 Download PDFInfo
- Publication number
- CN107391968B CN107391968B CN201710712125.0A CN201710712125A CN107391968B CN 107391968 B CN107391968 B CN 107391968B CN 201710712125 A CN201710712125 A CN 201710712125A CN 107391968 B CN107391968 B CN 107391968B
- Authority
- CN
- China
- Prior art keywords
- private
- spec
- pod
- warehouse
- new branch
- 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 38
- 238000012550 audit Methods 0.000 claims abstract description 23
- 238000004891 communication Methods 0.000 claims abstract description 13
- 230000006870 function Effects 0.000 claims description 19
- 230000005540 biological transmission Effects 0.000 claims description 3
- 230000008569 process Effects 0.000 abstract description 10
- 238000012986 modification Methods 0.000 description 10
- 238000012795 verification Methods 0.000 description 9
- 230000004048 modification Effects 0.000 description 8
- 238000010586 diagram Methods 0.000 description 6
- 238000012545 processing Methods 0.000 description 4
- 238000007726 management method Methods 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 101100409014 Rhizobium meliloti (strain 1021) ppdK gene Proteins 0.000 description 2
- 230000001419 dependent effect Effects 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 239000010979 ruby Substances 0.000 description 2
- 229910001750 ruby Inorganic materials 0.000 description 2
- 230000001066 destructive effect Effects 0.000 description 1
- 238000007429 general method Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
- G06F21/105—Arrangements for software license management or administration, e.g. for managing licenses at corporate level
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/20—Software design
- G06F8/22—Procedural
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Multimedia (AREA)
- Technology Law (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Storage Device Security (AREA)
Abstract
本发明提供一种实现私有pod发布权限控制的方法及装置，包括：S1，执行预编写好的私有pod发布脚本将待发布的私有pod的podspec文件提交到本地私有spec仓库的新分支中，并将所述新分支推送到远程私有spec仓库，并创建合并请求；S2，当所述远程私有spec仓库所对应的服务器接收到所述合并请求时，通知所述远程私有spec仓库的管理员对所述新分支中的podspec文件的内容进行审核；若审核结果为通过，则将所述新分支与所述远程私有spec仓库的master分支合并。本发明能够便利地实现对私有pod发布流程的权限控制，同时不增加spec仓库管理员与开放人员之间的沟通成本。
Description
技术领域
本发明涉及软件开发领域，更具体地，涉及一种实现私有pod发布权限控制的方法及装置。
背景技术
在iOS开发中，cocoapods是最常用的依赖包管理工具，越来越多的公司开始将自己开发的常用的工具库封装成pod(依赖包)来提供给公司自己的项目使用，考虑到商业机密与版权问题，这些pod都不会发布到cocoapods提供的开放spec仓库中，而是发布到内部的spec仓库中。
通常发布私有pod的方法是先运行podlib lint命令对podspec文件进行验证，然后运行podrepopush命令将私有pod的podspec文件发布到私有spec仓库中。此方案中将私有pod发布到私有spec仓库时，需要每个发布pod的人都要拥有私有spec仓库的master分支的push权限(即写权限)。这样对私有spec仓库来说是非常危险的，太多人拥有push权限，一旦某个人员产生错误操作或破坏性操作，都将导致spec仓库不可用。
若要给此发布流程加上权限控制，目前通用的方法是对私有spec仓库的master分支进行保护，只对少量的管理员开放push权限，所有pod的开发人员在开发完成之后编写好podspec文件，然后将此文件发送给管理员，再由管理员运行pod lib lint验证，运行podrepo push命令来进行发布。此方案加入了管理员审核环节，实现了发布流程的权限控制。但此方案对pod的开发人员和spec仓库的管理员来说操作都比较麻烦。加入权限控制之前，pod的开发人员只需要运行两条命令即可完成发布，而此时也没有管理员的概念。加入权限控制之后，pod开发人员要将podspec文件手动发给spec仓库管理员，管理员在接收到之后再运行podlib lint命令对podspec文件进行验证和podrepo push命令来进行发布，若验证失败则还需要打回去让开发人员重新修改，可见此过程中增加了pod开发人员和spec仓库管理员的操作和沟通成本，不太便利。
发明内容
为了解决现有私有pod发布权限控制方案中存在的操作不够便利且沟通成本较高的问题，本发明提供一种实现私有pod发布权限控制的方法及装置。
根据本发明的一个方面，提供一种实现私有pod发布权限控制的方法，包括：
S1，执行预编写好的私有pod发布脚本，将待发布的私有pod的podspec文件提交到本地私有spec仓库的新分支中，并将所述新分支推送到远程私有spec仓库，并创建合并请求；
S2，当所述远程私有spec仓库所对应的服务器接收到所述合并请求时，通知所述远程私有spec仓库的管理员对所述新分支中的podspec文件的内容进行审核，若审核结果为通过，则将所述新分支与所述远程私有spec仓库的master分支合并。
其中，在所述步骤S1之前还包括：
将待发布的私有pod的名称和版本传入预编写好的私有pod发布脚本。
其中，所述步骤S1进一步包括：
S11，更新本地私有spec仓库，为本地私有spec仓库创建新分支；
S12，在所述新分支中，将待发布的私有pod的名称和版本传入预定义的函数中，执行所述预定义的函数将待发布的私有pod的podspec文件提交到所述本地私有spec仓库相应的版本中；
S13，将所述新分支推送到远程私有spec仓库；
S14，调用git平台中创建合并请求的API来创建合并请求。
其中，S12中执行所述预定义的函数将待发布的私有pod的podspec文件提交到所述本地私有spec仓库相应的版本中的步骤进一步包括：
S121，检查本地私有spec仓库所在的目录下是否存在以所述待发布的私有pod的名称命名的文件夹，若存在，则进入步骤S122，若不存在，则在本地私有spec仓库所在的目录下创建以所述待发布的私有pod的名称命名的文件夹；
S122，检查本地私有spec仓库所在的目录下是否存在以所述待发布的私有pod的版本命名的文件夹，若存在，进入步骤S123，若不存在，则在本地私有spec仓库所在的目录下的以所述待发布的私有pod的名称命名的文件夹中创建以所述待发布的私有pod的版本命名的文件夹；
S123，拼接所述待发布的私有pod的名称字符串得到待发布的私有pod的podspec文件名；
S124，将所述待发布的私有pod的podspec文件复制到本地私有spec仓库所在的目录下的以所述待发布的私有pod的名称命名的文件夹目录下的以所述待发布的pod的版本命名的文件夹中。
其中，S2中将所述新分支与所述远程私有spec仓库的master分支合并的步骤进一步包括：
接收到远程私有spec仓库的管理员在gitlab平台提供的网站上点击合并按钮的事件时，执行合并请求命令将所述新分支合并到master分支中。
根据本发明的另一个方面，提供一种实现私有pod发布权限控制的装置，包括：
发布模块，用于执行预编写好的私有pod发布脚本将待发布的私有pod的podspec文件提交到本地私有spec仓库的新分支中，并将所述新分支推送到远程私有spec仓库，并创建合并请求；
分支合并模块，用于当所述远程私有spec仓库所对应的服务器接收到所述合并请求时，通知所述远程私有spec仓库的管理员对所述新分支中的podspec文件的内容进行审核，若审核结果为通过，则将所述新分支与所述远程私有spec仓库的master分支合并。
其中，还包括：
参数传递模块，用于将待发布的私有pod的名称和版本传入预编写好的私有pod发布脚本。
其中，所述发布模块进一步包括：
分支创建子模块，用于更新本地私有spec仓库，为本地私有spec仓库创建新分支；
第一发布子模块，用于在所述新分支中，将待发布的私有pod的名称和版本传入预定义的函数中，执行所述预定义的函数将待发布的私有pod的podspec文件提交到所述本地私有spec仓库相应的版本中；
第二发布子模块，用于将所述新分支推送到远程私有spec仓库；
合并请求创建子模块，用于调用git平台中创建合并请求的API来创建合并请求。
根据本发明的另一个方面，提供一种实现私有pod发布权限控制的设备，包括存储器、处理器、以及总线，
所述处理器和存储器通过所述总线完成相互间的通信；
所述存储器存储有可被所述处理器执行的程序指令，所述处理器调用所述存储器中的程序指令，以执行如前任一所述的方法。
根据本发明的又一个方面，提供一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令使所述计算机执行如前任一所述的方法。
本发明提出的一种实现私有pod发布权限控制的方法及装置，能够便利地实现对私有pod发布流程的权限控制，使得在不开放spec仓库push权限的情况下让开发人员自己发布私有pod，同时不增加spec仓库管理员与开放人员之间的沟通成本。
附图说明
图1为本发明一实施例提供的一种实现私有pod发布权限控制的方法的流程示意图；
图2为本发明另一实施例提供一种实现私有pod发布权限控制的方法中步骤S1的流程示意图；
图3为本发明另一实施例提供的一种实现私有pod发布权限控制的装置的结构示意图；
图4为本发明另一实施例提供的一种实现私有pod发布权限控制的装置中发布模块的结构示意图；
图5为本发明另一实施例提供的一种实现私有pod发布权限控制的设备的结构示意图。
具体实施方式
下面结合附图和实施例，对本发明的具体实施方式作进一步详细描述。以下实施例用于说明本发明，但不用来限制本发明的范围。
首先对本发明中涉及的相关术语进行解释：
git：开源的分布式版本控制工具，用于敏捷高效地处理任何或小或大的项目；
cocoapods：基于ruby开发的开源iOS依赖包管理工具；
pod：cocoapods中将每个依赖包称为pod；
podspec文件：pod的描述文件，包含作者、描述、类型、动态/静态库依赖等信息；
spec仓库：用来托管podspec文件的git仓库；
开放spec仓库：cocoapods提供的一个git仓库，用来存放所有的公共pod的podspec文件；
私有spec仓库：一般为使用公司内部git服务托管的spec仓库；
公共pod：podspec文件托管在cocoapods提供的git仓库中的pod；
私有pod：podspec文件托管在私有git仓库中的pod；
gitlab：一个基于ruby开发的开源git托管服务器项目，目前绝大多数公司内部的git服务都是通过gitlab搭建。
如图1所示，为本发明一实施例提供的一种实现私有pod发布权限控制的方法的流程示意图，包括：
S1，执行预编写好的私有pod发布脚本将待发布的私有pod的podspec文件提交到本地私有spec仓库的新分支中，并将所述新分支推送到远程私有spec仓库，并创建合并请求；
S2，当所述远程私有spec仓库所对应的服务器接收到所述合并请求时，通知所述远程私有spec仓库的管理员对所述新分支中的podspec文件的内容进行审核，若审核结果为通过，则将所述新分支与所述远程私有spec仓库的master分支合并。
具体地，合并请求是git中一种权限管理的扩展概念，通过对master分支进行保护，非管理人员对master分支只有读取的权限，没有写的权限，非管理人员的所有提交都只能通过基于master分支创建新分支，在该新分支上进行修改之后提交到远程git服务器，再发起合并请求。
为了让没有远程spec仓库master分支push权限的人员能够完成私有pod的发布，本发明实施例利用git中的合并请求机制让开发人员在发布私有pod时从本地spec仓库的master分支新建一个分支，将待发布的私有pod的podspec文件提交到该新分支中，然后将该新分支提交并推送(push)至远程私有spec仓库，之后发起合并请求，远程spec仓库的管理员在收到合并请求之后对该分支的变更内容进行审核，若审核通过则同意其合并请求，此时远程spec仓库服务器会将该分支合并到master分支，从而完成私有pod的发布，配合unix命令行工具，以上流程可以通过一个预先编写好的自动化脚本来完成。
步骤S1，执行预编写好的私有pod发布脚本pod_push.sh，此脚本接收两个参数，一个为待发布的私有pod的名称pod_name，另一个为待发布的私有pod的版本pod_version，该脚本主要用于将私有pod发布到远程私有spec仓库中，主要处理流程为：创建本地spec仓库的新分支＝>提交待发布的私有pod的podspec文件到本地spec仓库的新分支中＝>推送新分支到远程spec仓库＝>创建合并请求。
例如，待发布的私有pod为podA2.1，通过执行shpod_push.shpodA2.1命令取代podrepo pushpodA命令，对私有pod的发布者来说只是将发布命令换成了另外一条执行脚本的命令，没有增加开发人员的操作步骤，使用成本并未增加，但是通过本步骤中的流程可以实现让没有远程spec仓库master分支push权限的人员完成私有pod的发布。
步骤S2中，当远程私有spec仓库服务器接收到合并请求时，会通知远程私有spec仓库的管理员对所述新分支中的podspec文件的内容进行审核，通知的形式可以是邮件或其他形式，告知管理员有人创建了合并请求请立即处理。管理员按照一定审核标准对待发布的私有pod的podspec文件的内容进行审核，若审核通过，则将所述新分支合并到master分支，从而完成私有pod发布。使用方可以通过pod searchpodA查询podA的相关信息。
此步骤管理员通过对合并请求的审核达到对私有pod发布者发布的pod的质量把控，同时也将spec仓库的管理权限把握在自己手中，达到权限控制的目的。传统方案中管理员需要接收pod开发人员发送过来的podspec文件，再对该podspec文件运行pod lib lint命令验证，如果验证不通过还需要与该pod开发人员再进行沟通打回去重新修改，如果验证通过再运行pod repo push命令进行发布。本发明避免了pod开发人员和spec仓库管理员的直接沟通，降低了沟通成本。
本发明提出的一种实现私有pod发布权限控制的方法，能够便利地实现对私有pod发布流程的权限控制，使得在不开放spec仓库push权限的情况下让开发人员自己发布私有pod，同时不增加spec仓库管理员与开放人员之间的沟通成本。
基于上述实施例，在所述步骤S1之前还包括：
将待发布的私有pod的名称和版本传入预编写好的私有pod发布脚本。
执行预编写好的私有pod发布脚本pod_push.sh前，先将待发布的私有pod的名称pod_name和版本pod_version传入预编写好的私有pod发布脚本，即私有pod发布脚本接收两个参数，一个为待发布的私有pod的名称pod_name，另一个为待发布的私有pod的版本pod_version。
如图2所示，为本发明另一实施例在上述实例的基础上提供的步骤S1的流程示意图，步骤S1进一步包括：
S11，更新本地私有spec仓库，为本地私有spec仓库创建新分支；
在创建新分支前，需要更新本地spec仓库，以保证当前spec仓库为最新版本，这样就可以保证此次对spec仓库的修改是基于最近一次的修改进行的，始终保证统一的版本控制。具体地，步骤S11包括：
S11a，运行命令git-C Private_Spec_Repo_Pathpull originmaster更新本地的私有spec仓库，其中Private_Spec_Repo_Path为本地私有spec仓库的所在目录；
S11b，运行命令git-C Private_Spec_Repo_Path checkout-b feature/add_pod_name为本地私有spec创建新分支feature/add_pod_name_version。
S12，在所述新分支中，将待发布的私有pod的名称和版本传入预定义的函数中，执行所述预定义的函数将待发布的私有pod的podspec文件提交到所述本地私有spec仓库相应的版本中；
在所述新分支中，将待发布的私有pod的pod名称(pod_name)和pod版本(pod_version)传入预定义的函数publish_pod_to_spec中，执行publish_pod_to_spec函数将待发布的私有pod的podspec文件提交到所述本地私有spec仓库相应的版本中，即是指将待发布的私有pod的podspec文件提交至本地私有spec所在的目录下的相应文件夹中。
S13，将所述新分支推送到远程私有spec仓库；
执行命令git-C Private_Spec_Repo_Path add.&&git-C Private_Spec_Repo_Path commit-a-m“Add pod pod_name pod_version”&&git-C Private_Spec_Repo_Pathpush origin feature/add_pod_name_version将对本地私有spec仓库的修改提交并推送到远程私有spec仓库服务器，对本地私有spec仓库的修改即是指将待发布的私有pod提交到新分支中。
S14，调用git平台所提供的创建合并请求的API来创建合并请求。
调用具体的版本控制平台(如github或gitlab等)所提供的创建合并请求API来创建合并请求。
基于上述实施例，S12中执行所述预定义的函数将待发布的私有pod的podspec文件提交到所述本地私有spec仓库相应的版本中的步骤进一步包括：
S121，检查本地私有spec仓库所在的目录下是否存在以所述待发布的私有pod的名称命名的文件夹，若存在，则进入步骤S122，若不存在，则在本地私有spec仓库所在的目录下创建以所述待发布的私有pod的名称命名的文件夹；
S122，检查本地私有spec仓库所在的目录下是否存在以所述待发布的私有pod的版本命名的文件夹，若存在，进入步骤S123，若不存在，则在本地私有spec仓库所在的目录下的以所述待发布的私有pod的名称命名的文件夹中创建以所述待发布的私有pod的版本命名的文件夹；
S123，拼接所述待发布的私有pod的名称字符串得到待发布的私有pod的podspec文件名；
S124，将所述待发布的私有pod的podspec文件复制到本地私有spec仓库所在的目录下的以所述待发布的私有pod的名称命名的文件夹目录下的以所述待发布的私有pod的版本命名的文件夹中。
具体地，S121，检查本地私有spec仓库的所在目录Private_Spec_Repo_Path中是否存在以待发布的私有pod的名称pod_name命名的文件夹，若存在，则进入步骤S122，若不存在，则运行mkdir Private_Spec_Repo_Path/pod_name命令，在Private_Spec_Repo_Path目录下创建以所述待发布的私有pod的名称pod_name命名文件夹；
S122，检查是否存在以待发布的私有pod的版本pod_version命名的文件夹，若存在，进入步骤S123，若不存在，则运行mkdir Private_Spec_Repo_Path/pod_name/pod_version命令，在Private_Spec_Repo_Path/pod_name目录下创建以所述待发布的私有pod的版本pod_version命名的文件夹；
S123，拼接字符串pod_name与podspec，得到podspec文件名pod_name.podspec；
S124，运行命令cp pod_name.podspec Private_Spec_Repo_Path/pod_name/pod_versoin/将podspec文件复制到本地私有spec仓库的所在的目录下的文件夹Private_Spec_Repo_Path/pod_name/pod_versoin/中。
基于上述实施例，S2中将所述新分支与所述远程私有spec仓库的master分支合并的步骤进一步包括：
接收到远程私有spec仓库的管理员在gitlab平台提供的网站上点击合并按钮的事件时，执行合并请求命令将所述新分支合并到master分支中。
当所采用的版本控制平台为gitlab时，将所述新分支与所述远程私有spec仓库的master分支合并是平台自动完成的，远程私有spec仓库的管理员在进行私有pod发布操作时，只需要点击一个合并按钮即可完成发布工作，远程私有spec仓库服务器接收到远程私有spec仓库的管理员在gitlab平台提供的网站上点击合并按钮的事件时，执行合并请求命令将所述新分支合并到master分支中。
如图3所示，为本发明另一实施例提供的一种实现私有pod发布权限控制的装置的结构示意图，包括：发布模块31和分支合并模块32，其中，
发布模块31用于执行预编写好的私有pod发布脚本将待发布的私有pod的podspec文件提交到本地私有spec仓库的新分支中，并将所述新分支推送到远程私有spec仓库，并创建合并请求；
分支合并模块32用于当所述远程私有spec仓库所对应的服务器接收到所述合并请求时，通知所述远程私有spec仓库的管理员对所述新分支中的podspec文件的内容进行审核，若审核结果为通过，则将所述新分支与所述远程私有spec仓库的master分支合并。
为了让没有远程spec仓库master分支push权限的人员能够完成pod的发布，本发明实施例利用git中的合并请求机制让开发人员在发布私有pod时从本地spec仓库的master分支新建一个分支，将待发布的私有pod的podspec文件提交到该分支中，然后将该分支提交并推送(push)至远程私有spec仓库，之后发起合并请求，远程spec仓库管理员在收到合并请求之后对该分支的变更内容进行审核，若审核通过则同意其合并请求，此时会将该分支合并到master分支，从而完成私有pod的发布，配合unix命令行工具，以上流程可以通过一个预先编写好的自动化脚本来完成。
发布模块31执行预编写好的私有pod发布脚本pod_push.sh，此脚本接收两个参数，一个为待发布的私有pod的名称pod_name，另一个为待发布的私有pod的版本pod_version，该脚本主要用于将私有pod发布到远程私有spec仓库中，主要处理流程为：创建本地spec仓库的新分支＝>提交待发布的私有pod的podspec文件到本地spec仓库的新分支中＝>推送新分支到远程spec仓库＝>创建合并请求。
例如，待发布的私有pod为podA2.1，通过执行shpod_push.shpodA2.1命令取代podrepo pushpodA命令，对pod的发布者来说只是将发布命令换成了另外一条执行脚本的命令，没有增加开发人员的操作步骤，使用成本并未增加，但是通过本步骤中的流程可以实现让没有远程spec仓库master分支push权限的人员完成pod的发布。
分支合并模块32用于当所述远程私有spec仓库服务器接收到合并请求时，通知所述远程私有spec仓库的管理员对所述新分支中的podspec文件的内容进行审核，通知的形式可以是邮件或其他形式，告知管理员有人创建了合并请求请立即处理。管理员按照一定审核标准对待发布的私有pod的podspec文件的内容进行审核，若审核通过，则分支合并模块32将所述新分支合并到master分支，从而完成私有pod发布。使用方可以通过podsearchpodA查询podA的相关信息。
管理员通过对合并请求的审核达到对pod发布者发布的pod的质量把控，同时也将spec仓库的管理权限把握在自己手中，达到权限控制的目的。传统方案中管理员需要接收pod开发人员发送过来的podspec文件，再对该podspec文件运行pod lib lint命令验证，如果验证不通过还需要与该pod开发人员再进行沟通打回去重新修改，如果验证通过再运行podrepo push命令进行发布。本发明实施例避免了pod开发人员和spec仓库管理员的直接沟通，降低了沟通成本。
本发明提出的一种实现私有pod发布权限控制的装置，能够便利地实现对私有pod发布流程的权限控制，使得在不开放spec仓库push权限的情况下让开发人员自己发布私有pod，同时不增加spec仓库管理员与开放人员之间的沟通成本。
基于上述实施例，所述装置还包括：
参数传递模块，用于将待发布的私有pod的名称和版本传入预编写好的私有pod发布脚本。
执行预编写好的私有pod发布脚本pod_push.sh前，参数传递模块先将待发布的依赖包pod的名称pod_name和版本pod_version传入预编写好的私有pod发布脚本，即私有pod发布脚本接收两个参数，一个为待发布的私有pod的名称pod_name，另一个为待发布的私有pod的版本pod_version。
如图4所述，为本发明另一实施例，基于上述实施例中所述发布模块的结构示意图，包括：分支创建子模块41、第一发布子模块42、第二发布子模块43和合并请求创建子模块44，其中，
分支创建子模块41，用于更新本地私有spec仓库，为本地私有spec仓库创建新分支；
第一发布子模块42，用于在所述新分支中，将待发布的私有pod的名称和版本传入预定义的函数中，执行所述预定义的函数将待发布的私有pod的podspec文件提交到所述本地私有spec仓库相应的版本中；
第二发布子模块43，用于将所述新分支推送到远程私有spec仓库；
合并请求创建子模块44，用于调用git平台所提供的创建合并请求的API来创建合并请求。
在创建新分支前，需要更新本地spec仓库，以保证当前spec仓库为最新版本，这样就可以保证此次对spec仓库的修改是基于最近一次的修改进行的，始终保证统一的版本控制。分支创建子模块41具体用于：
运行命令git-C Private_Spec_Repo_Path pull origin master更新本地的私有spec仓库，其中Private_Spec_Repo_Path为本地私有spec仓库的所在目录；
运行命令git-C Private_Spec_Repo_Path checkout-b feature/add_pod_name为本地私有spec创建新分支feature/add_pod_name_version。
第一发布子模块42，用于在所述新分支中，将待发布的私有pod的名称(pod_name)和版本(pod_version)传入预定义的函数publish_pod_to_spec中，执行publish_pod_to_spec函数将待发布的私有pod的podspec文件提交到所述本地私有spec仓库相应的版本中，即是指将待发布的私有pod的podspec文件提交至本地私有spec所在的目录下的相应文件夹中。
第二发布子模块43用于执行命令git-C Private_Spec_Repo_Path add.&&git-CPrivate_Spec_Repo_Path commit-a-m“Add pod pod_name pod_version”&&git-CPrivate_Spec_Repo_Path push origin feature/add_pod_name_version将对本地私有spec仓库的修改提交并推送到远程私有spec仓库服务器，对本地私有spec仓库的修改即是指将待发布的私有pod提交到新分支中。
合并请求创建模块44用于调用具体的版本控制平台(如github或gitlab等)所提供的创建合并请求API来创建合并请求。
如图5所示，为本发明另一实施例提供的一种实现私有pod发布权限控制的设备的结构示意图，包括存储器51、处理器52、以及总线53，
所述处理器52和存储器51通过所述总线53完成相互间的通信；
所述存储器51存储有可被所述处理器52执行的程序指令，所述处理器52调用所述存储器51中的程序指令，以执行如上述各实施例所述的方法，例如包括：S1，执行预编写好的私有pod发布脚本将待发布的私有pod的podspec文件提交到本地私有spec仓库的新分支中，并将所述新分支推送到远程私有spec仓库，并创建合并请求；S2，当所述远程私有spec仓库所对应的服务器接收到所述合并请求时，通知所述远程私有spec仓库的管理员对所述新分支中的podspec文件的内容进行审核，若审核结果为通过，则将所述新分支与所述远程私有spec仓库的master分支合并。
本发明又一实施例提供一种非暂态计算机可读存储介质，所述非暂态计算机可读存介质存储计算机指令，所述计算机指令使所述计算机执行如上述各实施例所述的方法，例如包括：S1，执行预编写好的私有pod发布脚本将待发布的私有pod的podspec文件提交到本地私有spec仓库的新分支中，并将所述新分支推送到远程私有spec仓库，并创建合并请求；S2，当所述远程私有spec仓库所对应的服务器接收到所述合并请求时，通知所述远程私有spec仓库的管理员对所述新分支中的podspec文件的内容进行审核，若审核结果为通过，则将所述新分支与所述远程私有spec仓库的master分支合并。
本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
以上所描述的实现私有pod发布权限控制的设备实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。
最后，本发明的方法仅为较佳的实施方案，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
Claims (6)
1.一种实现私有pod发布权限控制的方法，其特征在于，包括：
S1，执行预编写好的私有pod发布脚本，将待发布的私有pod的podspec文件提交到本地私有spec仓库的新分支中，并将所述新分支推送到远程私有spec仓库，并创建合并请求；
S2，当所述远程私有spec仓库所对应的服务器接收到所述合并请求时，通知所述远程私有spec仓库的管理员对所述新分支中的podspec文件的内容进行审核，若审核结果为通过，则将所述新分支与所述远程私有spec仓库的master分支合并；
其中，在所述步骤S1之前还包括：
将待发布的私有pod的名称和版本传入预编写好的私有pod发布脚本；
其中，所述步骤S1进一步包括：
S11，更新本地私有spec仓库，为本地私有spec仓库创建新分支；
S12，在所述新分支中，将待发布的私有pod的名称和版本传入预定义的函数中，执行所述预定义的函数将待发布的私有pod的podspec文件提交到所述本地私有spec仓库相应的版本中；
S13，将所述新分支推送到远程私有spec仓库；
S14，调用git平台中创建合并请求的API来创建合并请求。
2.根据权利要求1所述的方法，其特征在于，S12中执行所述预定义的函数将待发布的私有pod的podspec文件提交到所述本地私有spec仓库相应的版本中的步骤进一步包括：
S121，检查本地私有spec仓库所在的目录下是否存在以所述待发布的私有pod的名称命名的文件夹，若存在，则进入步骤S122，若不存在，则在本地私有spec仓库所在的目录下创建以所述待发布的私有pod的名称命名的文件夹；
S122，检查本地私有spec仓库所在的目录下是否存在以所述待发布的私有pod的版本命名的文件夹，若存在，进入步骤S123，若不存在，则在本地私有spec仓库所在的目录下的以所述待发布的私有pod的名称命名的文件夹中创建以所述待发布的私有pod的版本命名的文件夹；
S123，拼接所述待发布的私有pod的名称字符串得到待发布的私有pod的podspec文件名；
S124，将所述待发布的私有pod的podspec文件复制到本地私有spec仓库所在的目录下的以所述待发布的私有pod的名称命名的文件夹目录下的以所述待发布的私有pod的版本命名的文件夹中。
3.根据权利要求1所述的方法，其特征在于，S2中将所述新分支与所述远程私有spec仓库的master分支合并的步骤进一步包括：
接收到远程私有spec仓库的管理员在gitlab平台提供的网站上点击合并按钮的事件时，执行合并请求命令将所述新分支合并到master分支中。
4.一种实现私有pod发布权限控制的装置，其特征在于，包括：
发布模块，用于执行预编写好的私有pod发布脚本将待发布的私有pod的podspec文件提交到本地私有spec仓库的新分支中，并将所述新分支推送到远程私有spec仓库，并创建合并请求；
分支合并模块，用于当所述远程私有spec仓库所对应的服务器接收到所述合并请求时，通知所述远程私有spec仓库的管理员对所述新分支中的podspec文件的内容进行审核，若审核结果为通过，则将所述新分支与所述远程私有spec仓库的master分支合并；
其中，还包括：
参数传递模块，用于将待发布的私有pod的名称和版本传入预编写好的私有pod发布脚本；
其中，所述发布模块进一步包括：
分支创建子模块，用于更新本地私有spec仓库，为本地私有spec仓库创建新分支；
第一发布子模块，用于在所述新分支中，将待发布的私有pod的名称和版本传入预定义的函数中，执行所述预定义的函数将待发布的私有pod的podspec文件提交到所述本地私有spec仓库相应的版本中；
第二发布子模块，用于将所述新分支推送到远程私有spec仓库；
合并请求创建子模块，用于调用git平台中创建合并请求的API来创建合并请求。
5.一种实现私有pod发布权限控制的设备，包括存储器、处理器、以及总线，
所述处理器和存储器通过所述总线完成相互间的通信；
所述存储器存储有可被所述处理器执行的程序指令，所述处理器调用所述存储器中的程序指令，以执行如权利要求1至3任一所述的方法。
6.一种非暂态计算机可读存储介质，其特征在于，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令使所述计算机执行如权利要求1至3任一所述的方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710712125.0A CN107391968B (zh) | 2017-08-18 | 2017-08-18 | 一种实现私有pod发布权限控制的方法及装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710712125.0A CN107391968B (zh) | 2017-08-18 | 2017-08-18 | 一种实现私有pod发布权限控制的方法及装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107391968A CN107391968A (zh) | 2017-11-24 |
| CN107391968B true CN107391968B (zh) | 2019-12-10 |
Family
ID=60352807
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201710712125.0A Active CN107391968B (zh) | 2017-08-18 | 2017-08-18 | 一种实现私有pod发布权限控制的方法及装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN107391968B (zh) |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110187888A (zh) * | 2018-02-23 | 2019-08-30 | 武汉斗鱼网络科技有限公司 | 一种Pod发布方法、存储介质、电子设备及系统 |
| CN110413268B (zh) * | 2018-04-28 | 2023-11-10 | 武汉斗鱼网络科技有限公司 | 一种中间件验证方法、存储介质、设备及系统 |
| CN109101243B (zh) * | 2018-07-20 | 2021-12-28 | 福建天泉教育科技有限公司 | 一种iOS依赖库的同步方法及终端 |
| CN111124466A (zh) * | 2018-10-31 | 2020-05-08 | 上海哔哩哔哩科技有限公司 | 差异化通知方法、系统、计算机设备及可读存储介质 |
| CN109857449A (zh) * | 2019-01-17 | 2019-06-07 | 平安城市建设科技(深圳)有限公司 | 基于内网的代码管理方法、装置、终端及可读存储介质 |
| CN109901876A (zh) * | 2019-02-28 | 2019-06-18 | 携程旅游信息技术（上海）有限公司 | 代码评审方法、系统、设备及存储介质 |
| CN110442371B (zh) * | 2019-08-05 | 2022-08-16 | 武汉斗鱼网络科技有限公司 | 一种发布代码的方法、装置、介质及计算机设备 |
| CN111142895B (zh) * | 2019-11-26 | 2021-10-15 | 叮当快药科技集团有限公司 | 基于svn模块的项目中组件的同步更新方法和系统 |
| CN111399810A (zh) * | 2020-03-11 | 2020-07-10 | 杭州涂鸦信息技术有限公司 | 一种iOS应用程序动态组件化开发方法及其系统和设备 |
| CN112947907B (zh) * | 2020-03-23 | 2024-03-12 | 深圳市明源云科技有限公司 | 一种创建代码分支的方法 |
| CN112363990A (zh) * | 2020-11-09 | 2021-02-12 | 北京磨刀刻石科技有限公司 | 一种设计文件在线版本管理方法及装置 |
| CN113760234B (zh) * | 2021-09-06 | 2023-06-27 | 小叶子（北京）科技有限公司 | 一种软件开发方法和系统 |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103425630A (zh) * | 2012-11-30 | 2013-12-04 | 上海理工大学 | 协同系统构架及其一致性维护方法 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10176238B2 (en) * | 2014-09-26 | 2019-01-08 | Oracle International Corporation | Integrating object-based data integration tool with a version control system in centralized and decentralized environments |
-
2017
- 2017-08-18 CN CN201710712125.0A patent/CN107391968B/zh active Active
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103425630A (zh) * | 2012-11-30 | 2013-12-04 | 上海理工大学 | 协同系统构架及其一致性维护方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN107391968A (zh) | 2017-11-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107391968B (zh) | 一种实现私有pod发布权限控制的方法及装置 | |
| US10481903B2 (en) | On-demand database service system, method, and computer program product for validating a developed application | |
| JP5730290B2 (ja) | アプリケーションのコンポーネントをバージョン管理するシステム、方法及びコンピュータプログラムプロダクト | |
| US8327351B2 (en) | Application modification framework | |
| US5966715A (en) | Application and database security and integrity system and method | |
| US20130247136A1 (en) | Automated Validation of Configuration and Compliance in Cloud Servers | |
| US10114861B2 (en) | Expandable ad hoc domain specific query for system management | |
| US8732668B2 (en) | System and method of error handling in a platform as a service environment | |
| US10817387B2 (en) | Auto point in time data restore for instance copy | |
| US9459859B2 (en) | Template derivation for configuration object management | |
| US8650288B2 (en) | Runtime usage analysis for a distributed policy enforcement system | |
| US11321226B2 (en) | Joint validation across code repositories | |
| US11842187B2 (en) | Configuration-driven applications | |
| US20200192967A1 (en) | Page objects library | |
| GB2502998A (en) | Automatic creation of endpoint definition documents for different environments | |
| Lee et al. | Windows PowerShell 2.0 Bible | |
| US10805182B2 (en) | Provisioner disaster-recovery framework for platform-as-a-service offering | |
| US20230229435A1 (en) | Code management cross-support and synchronization | |
| US11704043B1 (en) | Backup and/or restore as a service | |
| US20240095003A1 (en) | Deployment of a multi-technology-stack application | |
| US20230359753A1 (en) | Cross-Landscape Package Replication | |
| Lossau | KAOS (abstract only) a knowledge aided operator's system for the VM operator's console |
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 |