boulder: Add '--build', '--mv-to-repo=', and '--re-index' flags #570
Conversation
610d806 to
7ac0f5d
Compare
7ac0f5d to
adcd90a
Compare
| // Check to see if the repo is in moss | ||
| let moss_cmd = std::process::Command::new("moss") | ||
| .args(["repo", "list"]) | ||
| .stdout(std::process::Stdio::piped()) | ||
| .output() | ||
| .expect("Couldn't get a list of moss repos"); |
There was a problem hiding this comment.
We can use moss APIs directly from Rust, we shouldn't need to invoke it as a separate executable.
There was a problem hiding this comment.
My thought here is I'd like to refactor both boulder and moss to have a shared library crate. This way they both can call shared logic and not rely directly upon each other. To me, and I could be wrong, invoking moss directly here reduces the refactoring later if that were to become a thing. It also marks where the refactoring needs to happen.
There was a problem hiding this comment.
Refactoring is much easier w/ the help of rustc / rust-analyzer :) If we broke these interfaces, we'd get no compilation errors here. We can also build a much better API if we handle this natively in moss lib, such as moss::repository::Manager::get(repo: &str) -> Option<Repository>.
| let mut boulder_build = Cmd::new("boulder") | ||
| .args(["build", "-u", "stone.yaml"]) | ||
| .stdout(Stdio::inherit()) | ||
| .stderr(Stdio::inherit()) | ||
| .spawn() | ||
| .expect("Failed to run boulder build command!"); |
There was a problem hiding this comment.
Same here, we can just call a common function directly vs re-invoking boulder from boulder.. cli::build::handle(..)
There was a problem hiding this comment.
Yes, I can definitely refactor this.
| let repos = String::from_utf8(moss_cmd.stdout).expect("Could not get the repo list from moss"); | ||
|
|
||
| let mv_repo = repos | ||
| .lines() | ||
| .filter_map(|line| { |
There was a problem hiding this comment.
Can we factor out the mv-to-repo / re-index logic and call the single function from both build and recipe branches? This can all just be handled within cli::build since its a side-effect of the build and when calling cli::build::handle from recipe, we can just forward these arguments.
There was a problem hiding this comment.
Yep, absolutely. I can make this change for sure.
| global = true, | ||
| help = "Build the recipe after successful completion of the subcommand" | ||
| )] | ||
| pub(crate) build: bool, |
There was a problem hiding this comment.
cli is part of main which isn't a library so pub(crate) and pub are semantically the same. Regardless I think having all fields as pub for these CLI parsing structs is fine.
There was a problem hiding this comment.
Sounds good! I'll replace it with pub.
Purpose
This PR is the cleaned up, ready to merge, work for #561.
Flag Usage
The
--buildflag is only to be used with the variations of therecipesub-command. It's purpose it to automatically run the build sub-command after the recipe sub-command's process has successfully completed.Example:
The
--mv-to-repo=flag is restricted to only be used when either thebuildsub-command or--buildflag has been used. It didn't make sense to allow it to be used with the other sub-commands or if something wasn't being newly built. It's purpose is to automatically all newly built .stone files to the designated - moss registered - repo. Contrary to thejust mv-localcommand, it does not automatically re-index the given repository.Examples:
Finally, the
--re-indexflag is given to automatically re-index the repo that was given to the--mv-to-repo=flag. Therefore, the--re-indexflag requires the--mv-to-repo=flag.Examples:
boulder build --mv-to-repo=local --re-index boulder recipe update --build --ver 1.0.0 --upstream "git|deadbeef" stone.yaml -w --re-index --mv-to-repo=local