84deb34035
Currently the forced progress in RunTool is trying to fit the output line into a terminal width, but it doesn't take into an account a situation when the terminal width is reported as zero. This manifests when running in docker image with redirected output and can be seen in the github workflow output for esp-idf-ci-action. docker run --rm -t my_ubuntu_esp python3 -c 'import os,sys; print(os.get_terminal_size(), sys.stdout.isatty())' os.terminal_size(columns=238, lines=59) True vs docker run --rm -t my_ubuntu_esp python3 -c 'import os,sys; print(os.get_terminal_size(), sys.stdout.isatty())' | tee os.terminal_size(columns=0, lines=0) True Since the output is reported as tty and the terminal width as 0, the fit_text_in_terminal() function returns empty string. I also verified this by running idf.py build inside a testing docker image. This fix adjusts the fit_text_in_terminal() function to return original line if the terminal width is zero. Also simplify the progress print and use same approach as ninja https://github.com/ninja-build/ninja/blob/master/src/line_printer.cc#L66 Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
idf.py extensions
Python modules (subdirectories and files) in this directory named [your_extension]_ext will be loaded as idf.py extensions.
If you want to provide extra extensions just provide ; separated list of directories with extensions in IDF_EXTRA_ACTIONS_PATH. Extensions will be loaded in alphanumeric order.
Command line arguments parsing and extension mechanism is implemented on top of Click (versions >=5.0 are supported).
They should define a function action_extensions(base_actions, project_path) where:
- base_actions - dictionary with actions that are already available for idf.py
- project_path - working dir, may be defaulted to
os.getcwd()
This function have to return a dict with 3 possible keys:
{
# Additional options that will be available from id
"global_options": [{
"names": ["--option-name"],
"help": "Help for option --option-name.",
}],
# List of functions that will have access to full app context, and can mangle with arguments
"global_action_callbacks": [global_callback],
# Additional subcommands for idf.py
"actions": {
"subcommand_name": {
"callback": subcommand_callback,
"help": "Help for subcommand.",
},
},
}
Where function global_callback(ctx, global_args, tasks) accepts 3 arguments:
- ctx - Click context
- global_args - dictionary of all available global arguments
- tasks - list of Task objects
And subcommand_callback(subcommand_name, ctx, args) accepts 3 arguments:
- subcommand_name - name of subcommand
- ctx - Click context
- args - list of command's arguments