Automation issues with TorizonCore Builder tool due to interactive teriminal assumptions

I’m surprised that the script setups aliases that run docker commands with -it (interactive terminal) flag. The only way to automate builds using industry standard CI/CD processes is to hack the script, unless I’m missing something obvious. We never run these commands manually, we always program a remote system to do them for us. I’m thinking we aren’t the only ones and are surprised this hasn’t been addressed yet.

We download the latest tool using wget and then run sed to fix this in our CI/CD process. Can this minor change that would be more user friendly for everyone doing CI/CD be resolved in a future release?


wget -O
sed ‘s/-it//’ >
. -a remote

Also, the aliases that are set only work in interactive terminals without some additional tweaks. This could also use some user friendly tweaks. We worked around it by always sourcing our scripts that wrap the TorizonCore Builder Tool script and ensure our scripts run ‘shopt -s expand_aliases’.

I highly recommend that Torizon core build tools get updates to be come user friendly for automation such as CI/CD build processes.

Greetings @eldonmetz,

Thank you for your feedback. Our team already has a ticket in their list to improve the integration of TorizonCore Builder into CI/CD frameworks. I’ll pass your feedback along to them.

If it helps as a reference we do run TorizonCore Builder through Gitlab CI/CD for testing purposes. The CI/CD file for this can be found here: torizoncore-builder/.gitlab-ci.yml at bullseye · toradex/torizoncore-builder · GitHub

I’m not sure what CI/CD framework you are using, but this might help as a rough guidance.

Best Regards,

Greetings @jeremias.tx ,

Thank you for the link and follow-up.

We use Jenkins for CI/CD. The file you referenced has a comment on line 180 with a TODO: to use I’m assuming that is left as a TODO due to issues with interactive terminal requirements. We could discard our use of that script also, but that adds quite a bit more work/understanding in initial build script and maintenance. We’ll stick with the the workarounds we have for now, but will look back on this if we need more guidance.