同步操作将从 openEuler/RISC-V 强制同步,此操作会覆盖自 Fork 仓库以来所做的任何修改,且无法恢复!!!
确定后同步将在后台操作,完成时将刷新页面,请耐心等待。
本文不是介绍如何将一个非成功状态下的包怎么build成功,而是从工作流程的角度介绍在openeuler riscv项目中通过OBS构建系统进行工作的常规流程。
在介绍工作流程之前,先介绍下个人开发者会接触到的构建资源,主要包含以下这些:
从观察和分析包开始,我们的常见流程是这样的(这个流程主要是初期对包的问题进行大致定位):
当我们确定一个包的问题必须通过修改源码来解决的时候,我们就需要执行以下流程:
注意:
在obs上提交的submit的时候, _service文件中的url不能是【个人gitee仓库】的地址,在向mainline提交submit之前,请将url修改为源码仓(也就是openeuler-risc-v)这个地址后再提交。
因为mainline默认只接受源码仓过来的源代码进行构建,这是流程和规范约束的。
在个人的obs上测试成功之后,咱们需要:
一个包修复完成,我们的终点是mainline工程下构建成功。在以上流程的执行过程中,我们会对每个关键流程进行监控,主要的跟踪表格详见共享Excel表格:
https://docs.qq.com/sheet/DUGNPekJQY1RLQ3RG
请大家执行以上的流程,并对自己跟踪的包的状态在上述表格中进行维护。
以ck包为例举例说明:
第一步:在个人gitee RISC-V仓库下修改 configuration/riscv_fork_list.yaml文件 按照格式,添加ck包(主要是name必须有,与src-openeuler一致)并提交PR,当PR被合并后服务端的CI工具会触发自动fork,这样https://gitee.com/openeuler-risc-v 才会有源码包ck可以fork。
第二步:从https://gitee.com/openeuler-risc-v fork ck包到个人gitee下。后续就可以在个人gitee、个人obs上修改代码并测试,构建成功则提交PR搭配openeuler-risc-v。
当OBS的openEuler:Mainline:RISC-V 工程完成了我们的构建目标,目标包都能反复构建成功(或者通过内部初测),达到发版状况的时候才会提交PR到上游。因此日常的工作流程中,不涉及到openeuler-risc-v向src-openeuler提交PR的过程。
这个操作将由riscv社区的管理员或者maintainer负责。
src-openeuler合并openeuler-risc-v的PR后,会由openeuler上游社区统一进行系统构建,测试,发布一个增加了支持riscv64的新操作系统版本。
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。