Conflicts:
- spiffs submodules version and hash changed to 0.2-221-gf5e26c4e9331
- protobuf-c submodule version and hash changed to v1.3.0
- ci files moved from tools/ci/config/ into .gitlab/ci/ in v4.4, so
host-test.yml and rules.yml were changed accordingly in tools/ci/config/.
- added patterns-submodule to rules.yml, because they were also added in
v4.4
- removed pytest dependency
This adds SBOM information for submodules, which are not managed
by Espressif. Meaning there is no fork for them in the espressif
namespace. Other submodules should add sbom.yml manifest file to
the root of their git repository.
The SBOM information for submodules is stored in the .gitmodules file.
Each SBOM related variable has the "sbom-" prefix and the following
variables may be used:
sbom-version:
submodule version
sbom-cpe:
CPE record if available in NVD. This will be used by the SBOM
tool to check for possible submodule vulnerabilities. The
version in the CPE can be replaced with the "{}" placeholder,
which will be replaced by the "sbom-version" value from above.
sbom-supplier:
Person or organization who is providing the submodule.
It has to start with "Person:" or "Organization:" prefix
as required by the SPDX-2.2 standard.
sbom-url:
URL to the project if exists, e.g. github.
sbom-description:
Project description.
sbom-hash:
Submodule SHA as recorded in the git-tree. This field is used by
CI to check that the submodule checkout hash and info in .gitmodules
are in sync. IOW if submodule is updated and it has SBOM info in
.gitmodules, the .gitmodules has to be updated too. The test is
part of this commit. The checkout has of the submodule can be found
by using "git submodule status".
Example for micro-ecc submodule
---8<---
[submodule "components/bootloader/subproject/components/micro-ecc/micro-ecc"]
path = components/bootloader/subproject/components/micro-ecc/micro-ecc
url = ../../kmackay/micro-ecc.git
sbom-version = 1.0
sbom-cpe = cpe:2.3🅰️micro-ecc_project:micro-ecc:{}:*:*:*:*:*:*:*
sbom-supplier = Person: Ken MacKay
sbom-url = https://github.com/kmackay/micro-ecc
sbom-description = A small and fast ECDH and ECDSA implementation for 8-bit, 32-bit, and 64-bit processors
sbom-hash = d037ec89546fad14b5c4d5456c2e23a71e554966
---8<---
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Rules for rules.yml
- Rules for
rules.yml
How to Develop With rules.yml?
How to Add a New Job?
check if there's a suitable .rules:<rules-you-need> template
- if there is, put this in the job
extends. All done, now you can close this window. (extendscould be array or string) - if there isn't
- check How to Add a New
RulesTemplate?, create a suitable one - follow step 1
- check How to Add a New
How to Add a New Rules Template?
check if there's a suitable .if-<if-anchor-you-need> anchor
- if there is, create a rule following
rulesTemplate Naming Rules.For detail information, please refer to GitLab Documentationrules-if. Here's an example.
.rules:dev:
rules:
- <<: *if-trigger
- <<: *if-dev-push
-
if there isn't
- check How to Add a New
ifAnchor?, create a suitable one - follow step 1
- check How to Add a New
How to Add a New if Anchor?
Create an if anchor following if Anchors Naming Rules. For detail information about how to write the condition clause, please refer to GitLab Documentation `only/except (advanced). Here's an example.
.if-schedule: &if-schedule:
if: '$CI_PIPELINE_SOURCE == "schedule"'
Naming Rules
Common Naming Rules
if a phrase has multi words, use _ to concat them.
e.g.
regular_test
if a name have multi phrase, use - to concat them.
e.g.
regular_test-example_test
if Anchors Naming Rules
- if it's a label:
.if-label-<label_name> - if it's a ref:
.if-ref-<ref_name> - if it's a branch:
.if-branch-<branch_name> - if it's a tag:
.if-tag-<tag_name> - if it's a operating system:
.if-os-mac - if it's multi-type combination:
.if-ref-<release_name>-branch-<branch_name>
Common Phrases/Abbreviations
-
no_label$BOT_TRIGGER_WITH_LABEL == null -
protected($CI_COMMIT_REF_NAME == "master" || $CI_COMMIT_BRANCH =~ /^release\/v/ || $CI_COMMIT_TAG =~ /^v\d+\.\d+(\.\d+)?($|-)/) -
target_testexample_testorcustom_testorunit_test-all_targets
rules Template Naming Rules
-
if it's os related:
.rules:os:<os_name> -
if it's tag related:
.rules:tag:<tag_1>-<tag_2> -
if it's label related:
.rules:labels:<label_1>-<label_2>By default, all
.rules:labelsshould include bothif-label-regular_testandif-protected-no-labelimplicitly, unless they have special postfixes:- slim:
regular_testnot included - only: only have the phrases listed
- slim:
-
if it's target test related:
.rules:tests:<test_type_1>-<test_type_2>By default, all
.rules:testsshould includeif-protected-no_labelimplicitly, unless they have special postfixes (same as above) -
if it needs to build at first, then do some target test:
.rules:build_tests:<test_type_1>-<test_type_2>By default, all
.rules:build_testsshould includeif-protected-no-label,if-label-build,if-label-regular-testimplictly, unless they have special postfixes (same as above) -
if a job supports all targets, use
-all_targetsas postfix
Reusable Shell Script tools/ci/utils.sh
It is used to put all the reusable shell script as small functions. If you want to set before_script: [] for you job, now you can set extends: .before_script_slim instead. it will only run source tools/ci/utils.sh
If you're developing CI shell scripts, you can use these functions without source. They're already included in all before_script
To run these commands in shell script locally, place source tools/ci/utils.sh at the very beginning.
Functions
CI Job Related
apply_bot_filteradd_gitlab_ssh_keysadd_github_ssh_keysadd_doc_server_ssh_keysfetch_submodulesget_all_submodules
Shell Script Related
error: log in red colorwarning: log in orange colorinfo: log in green colorrun_cmd: run the command with duration seconds inforetry_failed: run the command with duration seconds info, retry when failed