bug(dtgithub): cloneRepo expands the literal string "projectPath" as its target directory and reports success without cloning
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
调研方向
Start in pkg/dtgithub/github_repo_projects_store.go, reading projectCreator.cloneRepo and its CreateProject caller. Compare the intended local path with the path computed by addProjectToDataTugConfig, then confirm the desired clone-or-error behavior with the maintainer. Done means CreateProject no longer reports a successful clone when no clone occurred.
由索引模型根据 Issue 内容生成。
描述
What happens
projectCreator.cloneRepo resolves its local directory from the literal string "projectPath", not from any project path, and then clones nothing anyway. It returns nil regardless, so CreateProject reports the clone as successful.
Trigger
pkg/dtgithub/github_repo_projects_store.go:
func (c *projectCreator) cloneRepo() (err error) {
localDir := fsutils.ExpandHome("projectPath")
dirExists, _ := fsutils.DirExists(localDir)
if !dirExists {
parent := filepath.Dir(localDir)
_ = os.MkdirAll(parent, 0o755)
cloneUrl := c.repo.GetCloneURL()
if cloneUrl == "" {
cloneUrl = fmt.Sprintf("https://github.com/%s/%s.git", c.repoOwner, c.repoName)
_ = cloneUrl
}
//_, err = git.PlainClone(localDir, false, &git.CloneOptions{
// ...
}
return nil
}
"projectPath" has no ~ prefix, so ExpandHome returns it unchanged and the path is resolved relative to the process's working directory. The git.PlainClone call that would use it is commented out, and cloneUrl is computed and then discarded into _. The net effect is an os.MkdirAll on the current directory and nothing else.
CreateProject calls this between creating the repo and writing the project files, and treats the nil as "cloned":
if err = c.cloneRepo(); err != nil {
return fmt.Errorf("failed to clone GitHub repository '%s/%s': %w", c.repoOwner, c.repoName, err)
}
Expected
Either clone into the project's real local directory (~/datatug/github.com/{owner}/{repo}, as addProjectToDataTugConfig already computes), or return a "not implemented" error so the caller does not report success for work that never happened. A placeholder string should not be silently treated as a path.
Notes
Found while adapting the CLI to datatug-core v0.39.0's caller-supplied project id (#259); deliberately not fixed there, since finishing the clone is a feature decision rather than part of the id change. Third of three pre-existing defects on this code path — see the sibling issues on the panicking projectID split and on projectCreator's unset fields.
- 主要语言
- Go
- 星标
- 1
- 派生
- 0
- 平均合并
- 7 小时 18 分钟
- 30 天内合并 PR
- 181
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
datatug/datatug-cli 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 68/100
datatug/datatug-cli#261 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 84/100
datatug/datatug-cli#256 ·
维护者通常 1 天内回复
-
environments/state: detached HEAD returns 409, so environments can't be listed at a tag or commit未关闭
难度 3/5 1-2 天 新手友好度 68/100
datatug/datatug-cli#474 ·
维护者通常 1 天内回复
-
Handle dal.IsNullCondition (isNull / isNotNull) in chat joins, access policies and compare-facts未关闭
难度 4/5 3-5 天 新手友好度 55/100
datatug/datatug-cli#316 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 45/100
datatug/datatug-cli#247 ·
维护者通常 1 天内回复
查看 datatug/datatug-cli 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 78/100
VictoriaMetrics/operator#2772 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 82/100
Gaurav-Gosain/tuios#1316 ·
维护者通常 1 天内回复
-
area:auth documentation priority:low
难度 1/5 1-3 小时 新手友好度 86/100
维护者通常 1 天内回复
-
Mend: dependency security vulnerability
难度 2/5 1-3 小时 新手友好度 65/100
kube-tarian/sigrun#203 ·
-
难度 2/5 1-3 小时 新手友好度 72/100
kubernetes-csi/csi-driver-iscsi#485 ·
维护者通常 1 天内回复