cargo-pando
Perform tasks concurrently over multiple copies of your repo.
Example use cases:
- test your code against multiple rust releases in parallel
- test the index / stage of your repo to validate incremental changes
- test all commits in a given range in parallel to bisect a bug (TODO)
- do both of the above at the same time (TODO)
- run some other custom command across any of the above checkouts (TODO)
The name pando comes from the clonal colony of "multiple" trees that are actually one single organism. It is latin for "I spread out".
Stability
HERE BE DRAGONS. This extension is in the early stages of development and may cause data loss or worse. Only use if you're very comfortable with git and have backups.
There may also be backwards incompatible changes for each version.
Installation
Will be easily installable from crates.io once it's more mature.
)
Upgrading
How it Works
- Figure out what toolchains to run against, either from the CLI,
.travis.yml
, or just using all the installed ones. - Create a copy of the repo's code in
target/pando
per toolchain, e.g.target/pando/1.31.0
. Note that this is destructive. - Run
cargo +TOOLCHAIN_HERE test
or some other action in each copy of the repo. For example,cargo +1.31.0 test
intarget/pando/1.31.0/working_dir
.
Output is logged to target/pando/TOOLCHAIN_HERE/output
.
Examples
See cargo pando help
for more details.
Test the working directory against the toolchains listed in .travis.yml
:
Test against every installed toolchain except the default, limiting it to 2 cargo test
s at any given time:
Test each specified toolchain, but only doc tests:
Git
Test the given toolchain against the index (stage) of your repo. Useful if you're incrementally adding changes to a commit and you want to check that your work in progress still works.
TODO
- add support for indicatif
- read from travis CI config to determine toolchains to run against
- support working directory copy
- get target from cargo metadata instead of assuming
- refactor checkout source to hide git impls (keep index for now)
- toolchain selection flags
- fancier ones?
- invoke subtasks with --message-format=json for better output information?
- determine number of steps for task from dependency list? (means actions will have to run before fully setting up the bars?)
- tree selection
- support allowing failures from travis.yml
- add support for other exec targets
- cargo
- build
- cmdeach / cmdall
- shelleach / shellall
- document using cargo aliases to help with common sub-commands
- document helpful env vars
- consider
do
subsubcommand to make multiple actions easier (use square brackets for separation?) - tmux integration (might have to refactor when output is created, etc.)
- blog post
- colorize / emojify output