Add build-only host tests for LP-core custom linker layouts supplied through the
LINKER option. Cover the positive paths (a full-replacement layout, a
multi-region layout with a fixed-address section, a run-from-HP-mem layout, and
memory protection) and the link-time and configure-time checks (reset-vector
placement, sizing, shared-memory overrun, the MEMPROT RX/RW boundary, a missing
reset vector, and a missing LINKER script).
idf-ci emits a skip pipeline containing only a fake_pass job, with no
include of test_child_pipeline.yml, when the modified files match no
buildable apps. patch_buildv2_child_pipeline.py redefined
generate_pytest_child_pipeline unconditionally, assuming the included
template supplied its tags, image and assign_test stage via keyword
merge. With the template absent, the injected job was bare: no tags,
default test stage. It was scheduled on the wrong runner and failed,
turning the allow_failure build_child_pipeline_buildv2 bridge red on
every buildv2 MR whose changes produce an empty app matrix.
Return early when a fake_pass job is present so the child pipeline is
left untouched and skips, matching the default build path. Add a unit
test for the patch script and a host_test job to run it.
Refactor the esp_err_to_name() system to decouple esp_common from
higher-level components. Instead of a monolithic generated table,
each component registers its error codes into a dedicated linker
section (.esp_err_msg_table) via idf_define_esp_err_codes() in its
CMakeLists.txt.
New files:
- tools/err_codes_extract.py: extract ESP_ERR_* defines from headers to CSV
- tools/err_codes_to_c.py: generate C source placing entries into linker section
- tools/err_codes_to_rst.py: generate RST documentation from error codes
- tools/cmake/err_codes.cmake: CMake module providing idf_define_esp_err_codes()
- components/esp_common/include/esp_err_codes.h: esp_err_msg_t typedef
- components/esp_common/src/esp_err_to_name_new.c: new lookup using link-time array
- tools/test_apps/build_system/err_codes_check/: CI test app
Changes:
- Remove all optional component dependencies from esp_common/CMakeLists.txt
- Add .esp_err_msg_table section to all 5 linker scripts
- Register error codes in 18 components via idf_define_esp_err_codes()
- Add new scripts to .gitlab/ci/rules.yml build_check patterns
- use new scripts to generate doc and add CI validation
- Update esp_err.rst to add description of composable code registration
- feat(soc_caps): Enable BT Classic and BLE in esp32s31
- Add git submodule for ESP32-S31 bt controller lib files
- changed sdkconfig.defaults and README for Bluetooth Classic examples
- change(docs): Added vendor HCI documentations for ESP32-S31
- change(Bluedroid): Adapt to ESP32-S31 due to some API differences on
Bluetooth controller from ESP32
- change(bt): Modify CMakeLists.txt to support the Bluetooth dual-mode
architecture on ESP32-S31
- change(bt): Add ECC P-192 functions to tinycrypt
The 8bbcdb116d ("ci(gitlab): Improve tools host test dependencies")
removed `kconfig_new` from rules.yml leading to the following pre-commit
failure.
```bash
Check tools dir files
patterns...........................................................Failed
- hook id: check-tools-files-patterns
- exit code: 1
This test is used for making sure of all the tools dir files are
recorded in .gitlab/ci/rules.yml to trigger the related tests, except
those files should be excluded.
Missing Files:
tools/kconfig_new/prepare_kconfig_files.py
tools/kconfig_new/config.env.in
tools/kconfig_new/confgen.py
tools/kconfig_new/confserver.py
tools/kconfig_new/config_buildv2.env.in
Please add these files or glob patterns to ".gitlab/ci/rules.yml" and
put related files under ".patterns-<test_group>" block to trigger
related tests.
Or add them to "tools/ci/exclude_check_tools_files.txt" to exclude them.
```
Fixes: 8bbcdb116d ("ci(gitlab): Improve tools host test dependencies")
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Currently, the buildv2 tests are initiated using the same patterns as
the tests for the current build system. This means that any change in
the current build system will also trigger the buildv2 tests. Initially,
it might be wise not to block the CI for changes in the current build
system in case there is an issue with buildv2. Therefore, let's
explicitly start the buildv2 tests only when the buildv2 label is set.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
A new pytest_buildv2_system job has been added to execute selected tests
from the existing test_build_system test suite. Currently, only the
test_non_default_target.py is enabled. The ultimate goal is to run most
of the build system tests with buildv2. This should help ensure
compatibility between IDF build system v1 and v2.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Removed
- target markers. Now must use target as parametrization in esp-idf
- host test markers. Now will be automatically added with linux target and qemu marker
This adds an assembler for the BitScrambler assembly language,
plus unit tests for it. It also adds the loopback driver,
which can do BitScrambler operations on memory-to-memory
transfers. Documentation is also included.
The initial implementation of a diagnostic tool that collects valuable
information about esp-idf and failed build to assist in investigating
reported issues.
The gathered information includes environmental variables, details about
the python virtual environment, installed tools, platform information,
project_description.json, sdkconfig, build logs, map file, linker
scripts, and others.
usage:
1) create the default report
# allow diag to create the report directory name
$ idf.py diag
# explicitly specify the report directory
$ idf.py diag --output <report directory>
2) examine the contents of the generated <report directory> for
sensitive information and add additional content to the
<report directory>
3) create report archive zip file that can be shared or attached to
the reported issue
$ idf.py diag --zip <report directory>
The tool collects information as described in what are known as recipe
files. A recipe file is a YAML file, similar to an Ansible playbook or a
GitHub action, but much more simplified. Each recipe outlines how to
gather a set of related information. For instance, the manager.yml
recipe gathers data related to the component manager. Each recipe
includes metadata such as its description, tags, and steps. Tags are
used to determine which recipes to use; by default, all built-in recipes
located in tools/idf_py_actions/diag/recipes are used. Steps consist of
a list of commands to be executed. Currently, there are four commands:
file, exec, env, and glob. For more detailed information about recipes,
their format, and commands, please refer to
tools/idf_py_actions/diag/recipes/README.md.
Recipe example for component manager:
description: IDF Component Manager information
tags: [manager, base, project]
output: manager
steps:
- name: 'IDF Component Manager'
cmds:
- exec:
cmd: 'python -m idf_component_manager version'
output: manager.ver
- file:
path: '${PROJECT_DIR}/dependencies.lock'
- glob:
# Gather all idf_component.yml files from the project directory and
# save them in directories relative to the project directory within
# the idf_component directory.
pattern: 'idf_component.yml'
recursive: true
relative: true
path: '${PROJECT_DIR}'
output: 'idf_component/'
Create report for manager
1) all recipes with manager tag
$ idf.py diag --tag manager
2) use only the manager recipe explicitly; built-in recipes can be
referenced simply by their name, but all recipes can be referenced
by their path
$ idf.py diag --recipe manager
or
$ idf.py diag --recipe <full path>
To display available recipes, use
$ idf.py diag --list
and to verify recipes, use
$ idf.py diag --check
Both --list and --check honers the --tag and --recipe options.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
target test report:
- refactor the methods to ensure reusability
- cover report generation with tests
- introduce a known failure tests block in report
- add grafana link to testcases dashboard
This adds a simple test that tries to run idf_size.py help and check
if the process does not exit with error. This is just to make sure
that idf_size.py can be used with minimum required python version.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Sudeep Mohanty
Fu Hanxi
Guillaume Souchere
Evgeny Torbin
Marius Vikhammer
wangmengyang
Linyan Liu
ShenWeilong
David Cermak
Frantisek Hrbata
Roland Dobai
Euripedes Rocha Filho
Mahavir Jain
Marek Fiala
Peter Dragun
armando
Igor Udot
Xiao Xufeng
Jeroen Domburg
Ivan Grokhotkov
morris
Aleksei Apaseev
Roland Dobai