The CI uses the mirror-submodule-update.sh for non-permanent reassignment
of 3rdparty sub-modules to local mirrors (only for 'non-master' branches).
List of the mirrors in mirror-list.txt
You can use the script locally to speed up data retrieval on network problems
check_submodule_sync job uses 'GIT_STRATEGY: clone' to check the availability of public sources
CI: auto generate configs for test jobs
Currently CI test jobs are static configured by several pre-generated config files.
This approach have several disadvantages:
1. not flexible to select test cases to run, which is important feature of @bot
2. difficult to update test as we need to pre-generate quite a lot files
3. need to maintain extra config files in IDF
4. not flexible to support new test apps or chips, can't use some new features of test bench
Therefore we'll add assign_test stage between build and test, to generate configs for test jobs.
See merge request !738
IDF built app download config may change with some modification.
save the download configs for built APP in build stage.
then we can use the correct download config in test stage.
wear levelling
This MR adds wear levelling component. It presents an interface similar to the interface of spi_flash and esp_partition. Inside, it stores data inside a partition to in a way that reduces worst case number of erase cycles for any given sector.
Also included are APIs similar to the ones provided for SDMMC to mount FAT filesystem on top of the wear levelling partition. A simple example shows how this API can be used.
Ref TW10338.
See merge request !567
CI support for testing & deploying release tags & branches
For CI testing & deployment of release branches:
* Test release tags as well as branches
* Swap gitlab submodule URLs to github when testing release tags or branches.
These changes are already pushed to the release/v2.0 branch.
See merge request !604
CI: support running CI test on release branches
Patches will be cherry-picked to release branches after it's released. Therefore we need to run test jobs with the same strategy as master.
See merge request !551
Previous design was put test env config on local runners. It's not easy
to manage as test runners count growing. Now we'll put config files for
test runners to a Gitlab repository. Test runners will get its config
from Gitlab every time before running.
ci: deploy code and docs for tags
Currently deploy happens only for the master branch.
This change is needed to support tags in release branches.
See merge request !458
docs: use custom roles to generate GitHub links
This change replaces direct links to GitHub master branch with
auto-generated links using docutils custom roles.
These auto-generated links point to the tree or blob for the git commit
ID (or tag) of the repository. This is needed to ensure that links don’t
become broken when files in master branch are moved around or deleted.
The following roles are introduced:
```
- :idf:`path` - points to directory inside ESP-IDF
- :idf_blob:`path` - points to file inside ESP-IDF
- :idf_raw:`path` - points to raw view of the file inside ESP-IDF
- :component:`path` - points to directory inside ESP-IDF components dir
- :component_blob:`path` - points to file inside ESP-IDF components dir
- :component_raw:`path` - points to raw view of the file inside ESP-IDF
components dir
- :example:`path` - points to directory inside ESP-IDF examples dir
- :example_blob:`path` - points to file inside ESP-IDF examples dir
- :example_raw:`path` - points to raw view of the file inside ESP-IDF
examples dir
```
A check is added to the CI build script, which searches RST files for
presence of hard-coded links (identified by tree/master, blob/master,
or raw/master part of the URL).
This check can be run manually: cd docs && make gh-linkcheck
Additionally, Sphinx linkcheck build type is used to create new CI test,
which check for broken links. This test has to be triggered explicitly,
because including it in normal build process (when the commit is not yet
deployed to Github) will not work. It can be triggered in a regular
fashion using a combination of cron and Curl, similar to stress tests.
See merge request !455
Anton Maklakov