alex/esp-idf
alex/esp-idf
1
0
Fork 0
mirror of https://github.com/espressif/esp-idf.git synced 2024-10-05 20:47:46 -04:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity
d4ab79259a
esp-idf/tools/ci/config
History
Frantisek Hrbata d4ab79259a tools: add sbom information for submodules 
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>
2023-06-16 07:34:49 +02:00
..
assign-test.yml CI: optimize ATS ci flow 2022-09-16 13:50:34 +08:00
build.yml ci: stop building & testing s3 apps 2022-11-03 17:22:03 +08:00
deploy.yml ci: allow scheduled pipelines 2022-08-15 10:43:11 +00:00
host-test.yml tools: add sbom information for submodules 2023-06-16 07:34:49 +02:00
post_check.yml ci: don't allow failure for submodule sync 2021-01-19 17:25:48 +08:00
post_deploy.yml CI: ignore result from check_doc_links 2021-03-18 13:15:24 +08:00
pre_check.yml ci: support one pipeline must based on commmits 2022-10-20 12:41:30 +00:00
README.md add README.md to explain how to add/modify jobs/rules/ifs 2020-10-26 10:25:21 +08:00
rules.yml tools: add sbom information for submodules 2023-06-16 07:34:49 +02:00
target-test.yml seperate ble wifi environment backport for v4.3 2023-01-12 17:42:12 +08:00

README.md

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

  1. if there is, put this in the job extends. All done, now you can close this window. (extends could be array or string)
  2. if there isn't
    1. check How to Add a New Rules Template?, create a suitable one
    2. follow step 1

How to Add a New Rules Template?

check if there's a suitable .if-<if-anchor-you-need> anchor

  1. if there is, create a rule following rules Template Naming Rules.For detail information, please refer to GitLab Documentation rules-if. Here's an example.
.rules:dev:
rules:
  - <<: *if-trigger
  - <<: *if-dev-push

  1. if there isn't

    1. check How to Add a New if Anchor?, create a suitable one
    2. follow step 1

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_test

    example_test or custom_test or unit_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:labels should include both if-label-regular_test and if-protected-no-label implicitly, unless they have special postfixes:

    • slim: regular_test not included
    • only: only have the phrases listed

  • if it's target test related: .rules:tests:<test_type_1>-<test_type_2>

    By default, all .rules:tests should include if-protected-no_label implicitly, 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_tests should include if-protected-no-label, if-label-build, if-label-regular-test implictly, unless they have special postfixes (same as above)

  • if a job supports all targets, use -all_targets as 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_filter
  • add_gitlab_ssh_keys
  • add_github_ssh_keys
  • add_doc_server_ssh_keys
  • fetch_submodules
  • get_all_submodules

Shell Script Related

  • error: log in red color
  • warning: log in orange color
  • info: log in green color
  • run_cmd: run the command with duration seconds info
  • retry_failed: run the command with duration seconds info, retry when failed