#工具链 #cargo #仓库 #多个 #任务 #命令 #pando

app cargo-pando

在多个仓库副本、多个工具链和/或 git 修订版本上并发执行任务

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日

#360Cargo 插件

MPL-2.0 许可证

33KB
629

cargo-pando   最新版本 Rustc 版本 1.34.2+ 构建状态

在多个仓库副本上并发执行任务。

  • 使用漂亮的进度条并行测试代码对多个 rust 版本
  • 测试仓库的索引/暂存区以验证增量更改
  • 同时执行上述两项操作
  • 在上述任一签出中运行一些其他自定义命令

名称 pando 来自于 “多个”树木的克隆种群,实际上是一个单一的生物体。它在拉丁语中意为“我扩展出去”。

稳定性

注意:此扩展处于早期开发阶段,可能会造成数据丢失或其他更严重的问题。只有在非常熟悉 git 并有备份的情况下才能使用。

每个版本也可能会有向后不兼容的更改。

安装

成熟后将从 crates.io 上轻松安装。

git clone (repo url here)
cd cargo-pando
cargo install --path .

升级

git pull origin master
cargo install --path . --force

工作原理

  1. 确定要运行的工具链,可以是 CLI、.travis.yml 或使用所有已安装的。
  2. 在每个工具链的目录中,在target/pando下创建代码库的副本,例如:target/pando/1.31.0。请注意,这是一个破坏性的操作。您在cargo配置中配置的目标目录将被尊重。
  3. 在每个代码库的副本中并行运行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