robotframework-tidy
robotframework-tidy copied to clipboard
Different behavior in ci run then local
We made a script to run robottidy. The script by default only checks but can be used to fix all formatting issues also by providing -f flag.
The gist:
CHECK="--check"
while test $# != 0
do
case "$1" in
-f|--fix) unset CHECK ;;
esac
shift
done
find ${DIRECTORIES_TO_CHECK_ROBOT} -name "*.robot"
robotidy --list
find ${DIRECTORIES_TO_CHECK_ROBOT} -name "*.robot" -exec robotidy -v ${CHECK} {} +
EXIT_CODE_ROBOT_TIDY=$?
if [ $EXIT_CODE_ROBOT_TIDY -ne 0 ]
then
# print the changes robotidy would make
find ${DIRECTORIES_TO_CHECK_ROBOT} -name "*.robot" -exec robotidy -v --diff --check {} +
echo "Format for robot code not ok"
else
echo "Done Checking format of robot code. Format ok."
fi
We observed different behavior, when executing that script locally and when executing in a ci-action. The ci-runner executes the same script. But there it seems robotidy does not detect misformating and returns with 0 exit code.
Any ideas what could be causing this? Or any workaround suggestions?
Could it have to do with interactive vs non-interactive shells?
Help is greatly appreciated.
Is there possiblity that one of the runs is picking up configuration file while the other not? Typically it should work in your case, unless the files are not passed to robotidy. I'm going to make Robotidy a bit more verbose in the next release so hopefully it will at least help catch issues with not getting files.
Is there possiblity that one of the runs is picking up configuration file while the other not? Typically it should work in your case, unless the files are not passed to robotidy. I'm going to make Robotidy a bit more verbose in the next release so hopefully it will at least help catch issues with not getting files.
Thanks for the help. Unlikely, we do not have a configuration file (yet).
@bhirsz, I retried:
I am basically doing robotidy PATH. There is no config-file. locally it works as expected.
in CI I get:
0 files would be reformatted, 0 files would be left unchanged.
Any idea, why this could be happening?
Returning to the issue. Were you able to resolve it or it still persist? @clamattia
I have one idea that Robotidy could take different source paths. If you run it with --verbose now Robotidy will print path to parsed files, so it may be useful for tracking if all files were found. In you case I wonder what $DIRECTORIES_TO_CHECK_ROBOT contains, if it's the same in the cli and local.
Returning to the issue. Were you able to resolve it or it still persist? @clamattia
I have one idea that Robotidy could take different source paths. If you run it with
--verbosenow Robotidy will print path to parsed files, so it may be useful for tracking if all files were found. In you case I wonder what$DIRECTORIES_TO_CHECK_ROBOTcontains, if it's the same in the cli and local.
Thank you.
Yes I reduced the example from the original:
check.sh:
robotidy /this/path/to/file
Running now check.sh locally produces the correct results and running in ci produces above output. I am relative confident, that the path is correct, because it is the result of a find command. I have tried verbose before. But I can retry and get back to you.