smitebot: Add smitebot build command

[Ashish-Kumar-Dash]

Adds smitebot build to build Smite workload Docker images without starting a fuzzing campaign.

The command selects the correct workload Dockerfile from --target, passes SCENARIO as the build arg, and tags images using the existing smite-<target>-<scenario> convention. It also supports coverage images, custom tags, and --no-cache for debugging rebuilds.

Validation:

• cargo fmt --all --check
• cargo clippy -p smitebot --all-targets --offline -- -D warnings
• cargo test -p smitebot --offline
• cargo run -p smitebot --offline -- build --help

[Ashish-Kumar-Dash]

ping @NishantBansal2003

[NishantBansal2003]

Great work! Some commands I tested are:

• smitebot build --target lnd --scenario ir

• smitebot build --target ldk --scenario noise --coverage --smite-dir ./smite

• Using cache: smitebot build --target ldk --scenario noise --coverage

• Without cache: smitebot build --target ldk --scenario noise --coverage --no-cache

• smitebot build --target cln --scenario encrypted_bytes --image cln-smitebot

Things I wanted to discuss are:

• In doctor.rs we use println! because the output is intended to be final and, in the JSON case, machine-parsable. However, smitebot build is not in the same situation, so I think we should use logging instead of println! and eprintln!. Using logs would also give us timestamps, which can be useful later for debugging. WDYT?
• For target, we already define the set of valid values, and those are also shown in smitebot help build. For scenario, however, we only accept a raw string. Would it make sense to define a fixed set of valid scenario values as well? The drawback is that every time a new scenario is added, smitebot would also need to be updated

[Ashish-Kumar-Dash]

• In doctor.rs we use println! because the output is intended to be final and, in the JSON case, machine-parsable. However, smitebot build is not in the same situation, so I think we should use logging instead of println! and eprintln!. Using logs would also give us timestamps, which can be useful later for debugging. WDYT?

Yes, I agree on logging for smitebot build. Using logs for smitebot’s own status/error messages seems cleaner. Docker output can still stream directly, and timestamps would help when debugging longer builds.

• For target, we already define the set of valid values, and those are also shown in smitebot help build. For scenario, however, we only accept a raw string. Would it make sense to define a fixed set of valid scenario values as well? The drawback is that every time a new scenario is added, smitebot would also need to be updated

tbh I’d prefer keeping it as a raw string for now. Targets are a fixed workload set, but scenarios are more likely to evolve in future, including IR/custom scenarios. Since the Dockerfiles already consume SCENARIO dynamically, hardcoding allowed scenarios in smitebot, like you pointed out as well, would add extra maintenance every time a scenario is added.