I'm trying to achieve something really simple: rebuilding a target in sonic-buildimage repository after some submodule service has changed.
Example scenario:
- Break compilation of src/sonic-swss/orchagent/main.cpp
- make target/docker-orchagent.gz
Expected output:
- target build fails
Actual output:
- the target is considered up to date
- removing the artifact target/docker-orchagent.gz allows for running make again
- running make again succeeds, suggesting that the upstream target/debs/bullseye/swss_1.0.0_amd64.deb was still not rebuilt.
Example:
user:~/sonic-buildimage$ echo "this is an invalid C++ line" >> src/sonic-swss/orchagent/main.cpp
user:~/sonic-buildimage$ (cd src/sonic-swss/ && git commit --all -m "invalid line should break compilation")
[master bbdc8db8] invalid line should break compilation
1 file changed, 1 insertion(+)
user:~/sonic-buildimage$ git commit --all -m "broken orchagent"
[master 22d791a92] broken orchagent
1 file changed, 1 insertion(+), 1 deletion(-)
user:~/sonic-buildimage$ make SONIC_BUILD_JOBS=4 NOSTRETCH=1 NOBUSTER=1 BLDENV=bullseye target/docker-orchagent.gz
make: 'target/docker-orchagent.gz' is up to date.
user:~/sonic-buildimage$ rm target/docker-orchagent.gz
user:~/sonic-buildimage$ make SONIC_BUILD_JOBS=4 NOSTRETCH=1 NOBUSTER=1 BLDENV=bullseye target/docker-orchagent.gz
# build output that succeeds
user:~/sonic-buildimage$ echo $?
0
In case of target/docker-orchagent.gz I know I should remove and rebuild target/debs/bullseye/swss_1.0.0_amd64.deb first, but that's obviously not a foolproof way of doing things.
Is there any way to force the sonic build system to honor such changes in upstream dependencies?
I feel like I'm missing some obvious features, but I haven't found a helpful doc.
Kind regards,
Łukasz