seccomp: add SYS_getcwd (79) to support proper Rust backtraces

When a proper Rust backtrace is printed, the Rust std wants to use the
SYS_getcwd(79) system call to prettify some paths while printing

seccomp: add SYS_getcwd (79) to support proper Rust backtraces

When a proper Rust backtrace is printed, the Rust std wants to use the
SYS_getcwd(79) system call to prettify some paths while printing. In
Cloud Hypervisor, this is at least relevant for printing panics or if
a `anyhow::Error` value is printed using `{e:?}` (but not `{e:#?}`).

The syscall cause can be found in `impl fmt::Display for Backtrace {}`
in `library/std/src/backtrace.rs`.

Without this addition, the seccomp violation of the SYS_getcwd (79)
hinders the proper error message including a full backtrace from showing
up. This annoying behaviour already delayed many debugging efforts. With
this fix, things just work. The new syscall itself should be pretty
harmless for normal operation.

```
thread 'vmm' panicked at virtio-devices/src/rng.rs:224:9:
Yikes, things went horribly wrong!

==== Possible seccomp violation ====
Try running with `strace -ff` to identify the cause and open an issue: https://github.com/cloud-hypervisor/cloud-hypervisor/issues/new
[1] 287683 invalid system call (core dumped) RUST_BACKTRACE=full cargo run --bin cloud-hypervisor -- --api-socket --kerne
```

```
thread 'vmm' panicked at virtio-devices/src/rng.rs:224:9:
Yikes, things went horribly wrong!
stack backtrace:
0: 0x557d91286b62 - std::backtrace_rs::backtrace::libunwind::trace::hc20b48b31ee52608
at /rustc/17067e9ac6d7ecb70e50f92c1944e545188d2359/library/std/src/../../backtrace/src/backtrace/libunwind.rs:117:9
1: 0x557d91286b62 - std::backtrace_rs::backtrace::trace_unsynchronized::h5d207cd20f193d88
at /rustc/17067e9ac6d7ecb70e50f92c1944e545188d2359/library/std/src/../../backtrace/src/backtrace/mod.rs:66:14

...

67: 0x0 - <unknown>
Error: Cloud Hypervisor exited with the following error:
Failed to join on VMM thread: Any { .. }

Debug Info: ThreadJoin(Any { .. })
```

- add any panic, for example into the create or drop function of a
device
- add --seccomp=true|log to analyze the situation

Signed-off-by: Philipp Schuster <philipp.schuster@cyberus-technology.de>
On-behalf-of: SAP philipp.schuster@sap.com

show more ...

ci: improve gitlint (max line length in body with exceptions)

Follow-up of 5aa1540c5dc33d61020a08dd2818c0f5fd08575f but way more
mature. We now use custom gitlint rules written in Python to better
h

ci: improve gitlint (max line length in body with exceptions)

Follow-up of 5aa1540c5dc33d61020a08dd2818c0f5fd08575f but way more
mature. We now use custom gitlint rules written in Python to better
handle the max line length, with respect to a few valid exceptions.
Recognizing code blocks or compiler output, as discussed, is not
trivial and hard to get right for all corner-cases. Therefore, this
commit is a pragmatic way forward. The CI job should be kept optional.

Allowed exceptions for the 72 line length limit are now:

1. links in the following three common patterns:
https://example.com/very-long-links/very-long-links/very-long-links/very-long-links/very-long-links/very-long-links/very-long-links
[0] https://example.com/very-long-links/very-long-links/very-long-links/very-long-links/very-long-links/very-long-links/very-long-links
[0]: https://example.com/very-long-links/very-long-links/very-long-links/very-long-links/very-long-links/very-long-links/very-long-links

2. code blocks (anything between the three backticks)

```
let x = "very_long_very_long_very_long_very_long_very_long_very_long_very_long_very_long_very_long_very_long_"
```

Signed-off-by: Philipp Schuster <philipp.schuster@cyberus-technology.de>
On-behalf-of: SAP philipp.schuster@sap.com

show more ...

gitlint: add openapi to valid components

See #6372

Signed-off-by: Ruslan Mstoi <ruslan.mstoi@intel.com>

ci: Remove Jenkinsfile

Most of our CI workers are now running form GitHub actions, so we are
ready to disable Jenkins CI workers.

See: #6231

Signed-off-by: Bo Chen <chen.bo@intel.com>

scripts: add main as a component

Main should be a component during the commit check.

Signed-off-by: Muminul Islam <muislam@microsoft.com>

gitlint: validate title components

Valid title format:
component1[, component2, componentN]: submodule: summary

Title should have at least one component
Components are separated by comma+space: ",

gitlint: validate title components

Valid title format:
component1[, component2, componentN]: submodule: summary

Title should have at least one component
Components are separated by comma+space: ", "
Components are validated to be in valid_components
Components list is ended by a colon
Submodules are not validated

See: #5846

Signed-off-by: Ruslan Mstoi <ruslan.mstoi@intel.com>

show more ...

gitlint: Increase the title length limit to 72

This is particularly useful for commits with long component names. Of
course, it is better to have concise subject that is less than 50 char.

Signed-o

gitlint: Increase the title length limit to 72

This is particularly useful for commits with long component names. Of
course, it is better to have concise subject that is less than 50 char.

Signed-off-by: Bo Chen <chen.bo@intel.com>

show more ...

build: add gitlint commit message linter

Implement commit message check workflow using gitlint

Fixes: #5840

Signed-off-by: Ruslan Mstoi <ruslan.mstoi@intel.com>