Angus Gratton 5938b9a892 Merge branch 'feature/support_esp32c3_master_cmake_reset_reason' into 'master' 5 tahun lalu
..
README.md 3026d562ec add README.md to explain how to add/modify jobs/rules/ifs 5 tahun lalu
assign-test.yml 9c8e4fd4c5 C3: build and run unit tests 5 tahun lalu
build.yml 4867b38c74 ci: sonarqube: use exit-code instead of extra job 5 tahun lalu
deploy.yml 7ad35fa5bb Merge branch 'bugfix/github_sync_artifacts' into 'master' 5 tahun lalu
host-test.yml 548ea1bdd5 tools: Wrap flash binaries into a UF2 file for flashing through USB MSC 5 tahun lalu
post_check.yml 3026d562ec add README.md to explain how to add/modify jobs/rules/ifs 5 tahun lalu
post_deploy.yml 71b24f0518 CI: Only run check_doc_links if we actually deployed 5 tahun lalu
pre_check.yml a47e207a7e ci: Fix annotated tag check 5 tahun lalu
rules.yml 9c8e4fd4c5 C3: build and run unit tests 5 tahun lalu
target-test.yml d23c7690f2 esp32c3: Add UTs for reset_reason 5 tahun lalu

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
    
  2. 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