4 个版本 (2 个破坏性更新)
0.3.0 | 2019年11月7日 |
---|---|
0.2.0 | 2019年2月9日 |
0.1.1 | 2019年1月8日 |
0.1.0 | 2019年1月8日 |
#360 在 Cargo 插件
33KB
629 行
cargo-pando
在多个仓库副本上并发执行任务。
- 使用漂亮的进度条并行测试代码对多个 rust 版本
- 测试仓库的索引/暂存区以验证增量更改
- 同时执行上述两项操作
- 在上述任一签出中运行一些其他自定义命令
名称 pando 来自于 “多个”树木的克隆种群,实际上是一个单一的生物体。它在拉丁语中意为“我扩展出去”。
稳定性
注意:此扩展处于早期开发阶段,可能会造成数据丢失或其他更严重的问题。只有在非常熟悉 git 并有备份的情况下才能使用。
每个版本也可能会有向后不兼容的更改。
安装
成熟后将从 crates.io 上轻松安装。
git clone (repo url here)
cd cargo-pando
cargo install --path .
升级
git pull origin master
cargo install --path . --force
工作原理
- 确定要运行的工具链,可以是 CLI、
.travis.yml
或使用所有已安装的。 - 在每个工具链的目录中,在
target/pando
下创建代码库的副本,例如:target/pando/1.31.0
。请注意,这是一个破坏性的操作。您在cargo配置中配置的目标目录将被尊重。 - 在每个代码库的副本中并行运行
rustup run TOOLCHAIN_HERE cargo test
或其他操作。例如,在target/pando/1.31.0/working_dir
中运行cargo +1.31.0 test
。
输出被记录在target/pando/TOOLCHAIN_HERE/output
,并且每行都紧挨着检出进度条打印。
注意事项
如果您的测试依赖于外部资源,请注意它们不会位于预期位置。
如果有独占资源,您将必须自行同步访问。
更多的并行化并不总是让事情更快,特别是在编译既可以是IO密集型也可以是CPU密集型的情况下。
示例
有关更多信息,请参阅cargo pando help
。
针对在.travis.yml
中列出的工具链测试工作目录
cargo pando test
测试除默认工具链之外的所有已安装工具链,同时限制在任何给定时间内的测试为2个cargo test
。
cargo pando --all test -j 2
测试每个指定的工具链,但只测试文档测试
cargo pando -t stable -t beta test -- --doc
如果您想一次性在所有检出中运行单个命令,请使用print、cut和xargs
cargo pando print | cut -f 2 | xargs ls
针对每个检出运行任意命令,并根据需要替换工具链的名称
cargo pando each echo the toolchain '{}' has been copied
如果命令不适合进度条给出的单行,xargs又可以帮上忙
cargo pando print | cut -f 1 | xargs -L 1 -P 2 echo the toolchain is
Git
将给定的工具链与您的代码库的索引(暂存)进行测试。如果您正在增量添加更改到提交中,并希望检查您的正在进行中的工作是否仍然有效,这很有用。
cargo pando --index -t stable test
有用的相关命令
查看pando目录占用的空间量
du -sh target/pando
删除它!
rm -rf target/pando
错误/开放问题
- 我们如何知道需要复制哪些文件?
- 我们如何知道何时/删除检出中的哪些文件?
- 我们如何确定工具链的规范名称,以避免在travis表示法和--all表示法之间重复?
待办事项
0.3
- 从cargo元数据中获取目标,而不是假设
- 添加对其他执行目标的支持
- 打印
- cargo
- 构建
- cmdeach
/ cmdall(让它打印并通过shell/xargs消耗它!)- 记录这一点
- 呃,记录一切
[ ] 使用cargo别名帮助记录常见的子命令[ ] 记录有用的环境变量
(我记不起最后两个是什么了。哦,算了。)
0.4
- 开始编写测试
- 呼吁(并获取)反馈
- 找出最早兼容的rust版本
- 支持允许travis.yml中的失败
1.0
- 博客文章
- 将进度条指向stdout
- 回答:是否需要比Cargo文件、测试和src更多的内容?(build.rs也许,然后更多?)
下一步
- 使用--message-format=json调用子任务以获取更好的输出信息?
- 从依赖列表中确定任务的步骤数?
- 着色/添加表情符号到输出
也许?
- tmux集成(在创建输出时可能需要重构等)
- 其他工具链选择/隔离机制?
- Docker?
- 我们能否随意支持这一点?可能不值得。
- 大量清理操作
- 使打印接收参数以选择字段分隔符(空白字符、空、ASCII制表符)
依赖关系
~18–30MB
~488K SLoC