CNB中能否直接使用Github Actions插件？#7
@Mr.d(嗯嗯) 因为根本就不是一个架构，cnb基于docker，你根本没法限定系统环境，github的插件很难迁移过来，可以看看cnb的官方插件
@haorwen(haorwen)
正因为基于docker，所以才应该有更多实现的可能性吧？
想要社区把Github action，那也得提供对GitHub action plugin生态的兼容吧？不然迁移一个包含过多插件的难道还要先提前完成对该action plugin的全部迁移？
以下内容由 AI 生成
GitHub Actions（GH Actions）与CNB（云原生构建）在架构和设计理念上的差异，确实会导致强行兼容时面临多重挑战，具体可从以下四点展开分析：
一、环境变量体系不兼容
GH Actions运行在GitHub定制化的执行环境中，内置了大量与CI/CD流程强相关的环境变量（如GITHUB_RUN_ID标识当前运行实例、GITHUB_WORKSPACE指向工作区路径、GITHUB_REF表示分支/标签等）。这些变量是GH Actions生态的核心元数据，用于控制任务执行逻辑（例如根据分支名触发不同任务）。而CNB作为容器化平台，其环境变量通常基于通用容器标准（如Docker的ENV指令或Kubernetes的env字段），更关注应用运行时的配置，缺乏与GH Actions流程强绑定的变量体系。若CNB强行兼容GH Actions的环境变量，需额外维护一套映射关系（例如将GITHUB_RUN_ID转换为CNB内部的运行ID），不仅增加配置复杂度，还可能因变量作用域（如GH Actions的steps级变量与CNB的任务级变量）不匹配导致逻辑错误。
二、语法体系差异显著
GH Actions使用YAML格式的工作流文件（.github/workflows/*.yml），其语法围绕“工作流（Workflow）- 作业（Job）- 步骤（Step）”三层结构设计，核心元素（如runs-on指定运行环境、steps中的uses调用Action插件、with传递参数）与CNB（.cnb.yml)的语法逻辑完全不同。例如，GH Actions中通过uses: actions/checkout@v4调用指定版本进行克隆代码，而CNB已经进化到 git-clone-yyds 无需用户手工克隆代码。
三、缓存机制设计目标冲突
GH Actions的缓存系统以“流程感知”为核心，通过jobs.<job_id>.steps.<step_id>.outputs传递缓存键（Cache Key），支持按路径（如node_modules）、键值（如version=v1.0）精确控制缓存范围，且缓存生命周期与Job/Step绑定（例如失败后自动清理）。而 CNB 的缓存机制，只需要声明即可用。与 cnb 的TB级缓存机制相比，gh 的缓存多少有点不够大，我们没必要去兼容一个不够大的缓存方案。
四、持续演进带来的维护压力
GH Actions的语法和生态处于快速迭代中：例如，近年新增了workflows的conclusion字段（支持success/failure等状态捕获）、jobs的container字段（直接指定运行容器），以及更复杂的表达式语法（如github.event.inputs接收外部输入）。这些变化要求CNB若要保持兼容，需持续跟进GH Actions的更新，否则迁移后的仓库可能因语法不兼容（如旧版YAML结构被废弃）或Action插件接口变更（如新Action需要env而非with传递参数）无法运行。此外，GH Actions的第三方Action生态（超5万个插件）不断更新功能（如从actions/checkout的submodules: true到actions/checkout@v4的fetch-depth: 0），CNB需为每个新Action开发适配逻辑，否则用户迁移仓库时将面临“插件不可用”的问题，维护成本和技术债务将大幅增加。
综上，GH Actions与CNB在环境变量、语法体系、缓存机制及生态演进上的根本差异，使得强行兼容需解决多重技术矛盾，实际落地难度极高。
根本的设计思路不同，就像 mac os 没有去完全兼容 windows。
CNB CI 是完全基于云原生的思路去做的，github action 是基于虚拟机的思路去做的。以 github action market 上最流行的一个 action yq 来举例
一个 github action 需要在仓库中定义 action.yml，其中指明如何运行该插件，是以虚拟机形式，还是 docker 形式。
https://github.com/mikefarah/yq/blob/master/action.yml
name: 'yq - portable yaml processor'
description: 'create, read, update, delete, merge, validate and do more with yaml'
branding:
icon: command
color: gray-dark
inputs:
cmd:
description: 'The Command which should be run'
required: true
outputs:
result:
description: "The complete result from the yq command being run"
runs:
using: 'docker'
image: 'docker://mikefarah/yq:4-githubaction'
args:
- ${{ inputs.cmd }}
可以看到 using: docker 的声明，但是在 CNB 上，我们是没有虚拟机这一层的。这就好比中国直接跳过了 pc 互联网，直接去移动互联网了。整个思路是不一样的。
针对 yq 这个 github action，你可以说 CNB 没有兼容，也可以说已经兼容了
Github Actions有太多的社区插件，这是目前CNB不足的，可够在CNB中提供直接使用Github Actions插件能力？