This hopefully resolves the problem with failing artifact upload.
Source of the changes: https://github.com/ossf/scorecard/, file
.github/workflows/scorecard-analysis.yml
The compiler produces a segfault on the emulated architectures. To be
able to continue the work on Wakaama we disable testing on these
architectures for the time being.
CodeChecker combines multiple static code analysis tools including
`clang-sa`. It also provides the possibility to check against a baseline
to report only newly introduced issues.
Moreover it is simpler to use.
It could eventually replace `clang-sa` completely in the pipeline.
The client example projects now use Wakaama as a direct dependency. They
have also been split into three different projects (udp, tinydtls and
raw_block1). The CI and integration tests were adjusted for the new
project.
OpenSSF scorecard does not want us to upgrade to unspecified versions.
Removing the update seems like the simplest solution, as the version
contained in the ubuntu-20.04 base image is recent enough.
Building and testing Wakaama on macOS with the default compiler and no
additional sanitizers. This makes sure that the code can be used with
macOS.
The integration tests don't work on macOS due to different timing
related to output on `stdout`.
The 'master' branch was renamed to 'main' to reduce the use of harmful
language. Therefore, some scripts and descriptions were adjusted to the
new name of the default branch.
Words matter!
SonarCloud Scan does no longer support Java 11. Use
`sonarsource/sonarcloud-github-c-cpp` action to install sonarcloud and
the build-wrapper directly from the original vendor instead of a third
party.
While (again) not an official release, this will advance us by 274
commits:
```
$ git rev-list --count 178b945e5497b813b1239e2fbf57e34b7488745f..HEAD
274
```
cmake-format ensures that our CMake code adheres to the format accepted
by cmake-format.
The code style is based on default one, with some minor adjustments.
Before this, the build system set many flags and defines globally,
making it hard-to-impossible to build binaries with freely chosen
combinations of defines in the same build tree.
With this new design, compilation flags are bound to their targets,
which is the preferred style since CMake ~3.0.
Pro:
- Unit tests and compilation checks can cover arbitrary (all!) defines
- Simplified usage when including Wakaama in a CMake based project:
- include wakaama.cmake
- add_executable(your-binary ...)
- target_compile_definitions(your-binary ...)
- target_sources_wakaama(your-binary)
- DTLS enabled example client built next to the plaintext one. This
will make it easier to integrate both binaries in the same
integration test run.
Con:
- Building the example client project requires the tinydtls submodule
to be checked out. Same goes for the top level "wakaama" project,
which includes the example client.
git-clang-format ensures that all *new* code being submitted adheres to
the format dictated by clang-format.
The code style is based on LLVM (the creator of clang-format), but with
4 instead of 2 spaces indent width and a maximum of 120 instead of 80
characters per line in order to blend in well with existing code.
Please note:
- The er-coap-13 code gets exempt, as at some point, we probably want to
to interact with whatever upstream there might be. For those files,
just do what existing code does (which varies every few lines).
- Default is clang-format-10, which is available in the Ubuntu 20.04
GitHub runner.
This workflow does not have gitlint installed, and does not need it.
Therefore it should not try to invoke it.
This error could get introduced because SonarCloud scan are running only
on master for now. See 866e5050838a9edf03ce79698823677f73635cb3 for
details.
This is a fairly default configuration, which, among other stuff,
checks for the subject line being 72 or less characters as required by
the Eclipse project handbook.
Non-default rules:
- Enforce at least 20 characters in the commit body
- Disallow the word "fixup" in the title messages. Intended to prevent
accidents like d31d026cb24bc88730c065d3be800a8d8e78e2b0.
In case any of those rules get in the way, use the "gitlint-ignore" tag
in the commit message to suppress gitlint findings for this specific
commit. To configure a rule permanently, adapt .gitlint.
The GitHub Action runs only on PRs, not after each push. The idea is to
prevent annoyance when working on code, using WIP or other non-compliant
commit messages.
