Proposal: Add an LLGo test workflow only when a binding project has tests
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 25/100
调研方向
Start with the project template that #974 introduced and the generation path that llcppg -init runs, then read the existing llcppg CI workflow at .github/workflows/llgo.yml as the reference setup. The open question, whether this belongs in ordinary generation or in an explicit template-sync command, needs a maintainer decision before any code. Done means a project with no *_test.go gets no workflow, one with tests gets it, and regeneration never overwrites a customized file.
由索引模型根据 Issue 内容生成。
描述
Summary
Add an llgo.yml workflow to the llcppg project template. When llcppg applies the template to a binding project, it should create .github/workflows/llgo.yml only if the target Go module contains at least one *_test.go file. The workflow runs llgo test ./... on pushes and pull requests. Projects without tests should not receive the workflow file.
Motivation
The template introduced in #974 gives new binding repositories a consistent starting point. Once a project adds tests, those tests should run automatically in CI using LLGo, as llcppg itself does. Adding a test workflow to every new repository would create a CI job that has nothing to test. Making the workflow conditional keeps the initial repository small while enabling CI when tests exist.
Proposed behavior
- Keep
llgo.ymlas a source file in the template. Materialize it at.github/workflows/llgo.ymlin the target repository only when a*_test.gofile exists under the target Go module. - Check after generation has written its files, so the decision reflects the project’s current contents. A fresh
llcppg -initrepository has no tests and therefore receives no workflow. - If tests are added later, the next template synchronization or generation run adds the workflow. The command should report when it does so.
- If no tests exist, leave
.github/workflows/llgo.ymlabsent. Do not delete an existing workflow: it may contain project-specific changes. - Do not overwrite an existing
llgo.ymlwhen applying the template.
The generated workflow should set up the required Go, LLVM, and LLGo toolchain, then run llgo test ./... from the module root. Its setup can follow the existing [llcppg CI workflow](https://github.com/goplus/llcppg/blob/main/.github/workflows/llgo.yml), adapted so it works in a generated binding repository.
Testing plan
Verify that a project with no *_test.go receives no workflow; a project with a test in the module root or a subpackage receives llgo.yml; and running generation again does not overwrite a customized workflow. Finally, run the generated workflow against a small binding project with a passing test.
Open question
Should adding the workflow be part of ordinary generation, or should template synchronization have an explicit command? Checking only during llcppg -init would miss the common case where tests are written after initialization.
- 主要语言
- Go
- 星标
- 39
- 派生
- 13
- 平均合并
- 1 小时 33 分钟
- 30 天内合并 PR
- 256
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
goplus/llcppg 的其他 Issue
-
难度 3/5 1-2 天 新手友好度 35/100
维护者通常 1 天内回复
-
configuration
难度 4/5 3-5 天 新手友好度 30/100
维护者通常 1 天内回复
-
Architecture-Design feature proposal
难度 5/5 一周以上 新手友好度 15/100
维护者通常 1 天内回复
-
bug
难度 5/5 一周以上 新手友好度 28/100
维护者通常 1 天内回复
-
bug
难度 4/5 3-5 天 新手友好度 55/100
维护者通常 1 天内回复
相似的 Issue
-
enhancement
难度 2/5 1-3 小时 新手友好度 70/100
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 70/100
superplanehq/superplane#8604 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
维护者通常 1 天内回复
-
documentation hacktoberfest priority: low skill: good first issue status: ready for dev
难度 2/5 半天 新手友好度 85/100
hyperledger-labs/fabric-smart-client#2142 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
numberly/vault-db-injector#107 ·
维护者通常 1 天内回复