Skip to content

ZIMO-Elektronik/.github-workflows

Repository files navigation

.github-workflows

build tests

.github-workflows bundles reusable GitHub workflows.

Table of contents
  1. Usage
  2. Limitations

Usage

arm-none-eabi-gcc

Uses the arm-none-eabi-gcc toolchain to build for various ARM platforms. The arch option is mandatory, target is optional. If no target is specified it defaults to all. Additional arguments to CMake can be passed with args.

jobs:
  arm-none-eabi-gcc:
    uses: ZIMO-Elektronik/.github-workflows/.github/workflows/[email protected]
    with:
      arch: -mcpu=cortex-m4
      args: -DCMAKE_BUILD_TYPE=Release
      target: YourTarget

esp-elf-gcc

Uses the ESP-IDF toolchain to build for various ESP platforms. The available options are the same as the ones from the original CI action.

jobs:
  esp-elf-gcc:
    uses: ZIMO-Elektronik/.github-workflows/.github/workflows/[email protected]
    with:
      path: examples/rmt
      esp_idf_version: v5.0
      target: esp32

license-checker

Uses the kt3k license-checker to check if a license is present in the files of a repository.

jobs:
  license:
    uses: ZIMO-Elektronik/.github-workflows/.github/workflows/[email protected]

The check requires a .licenserc.json file in the root of the repository.

{
  "{include,src}/**/*.{cpp,hpp}": [
    "// This Source Code Form is subject to the terms of the Mozilla Public",
    "// License, v. 2.0. If a copy of the MPL was not distributed with this",
    "// file, You can obtain one at https://mozilla.org/MPL/2.0/."
  ]
}

x86_64-linux-gnu-gcc

Uses a linux GCC toolchain to build for x86_64 platforms. The target option is optional. If no target is specified it defaults to all.

jobs:
  x86_64-linux-gnu-gcc:
    uses: ZIMO-Elektronik/.github-workflows/.github/workflows/[email protected]
    with:
      pre-build: |
        sudo apt update -y
        sudo apt install -y ninja-build
      args: -GNinja -DCMAKE_BUILD_TYPE=Release
      target: YourTarget AnotherTarget

Limitations

Tags

Warning

For whatever reason this repository must not use annotated git tags. I came across this through the following comment in a GitHub discussion:

I finally found out what is precisely the problem.

Well, in the GH doc it mentions that a release tag is needed, or a branch or a commit id.

The term release tag is inappropriate in the documentation, because we tested with a Git tag promoted in GitHub as a GitHub Release and it doesn't work better.

However, we figured out that if we use only a lightweight Git tag (rather than an annotated git tag), it works. So, as a result, for GitHub Workflows repositories, we need to avoid using annotated tags. This seem not possible to forbid as a configuration, so we need to be careful.

Anyway, GitHub doc is really confusing an not sufficient precise, which is too bad. Moreover, it is surprising that annotated tags doesn't work as their have more information inside. It seems that it such lack a resolution command... maybe could it be fixed in next version ?

tl;dr only use lightweight tags for versioning!

Running GitHub actions locally

Warning

To support running actions locally we currently can't use relative paths to workflows. This is a known issue with act (#1875).

tl;dr when pushing a new tag, update existing ones!