| commit | 0ad63df8aa8ab60f74395794d8ffce64c82ee031 | [log] [tgz] |
|---|---|---|
| author | Nan Zhou <nanzhoumails@gmail.com> | Mon Oct 17 23:03:21 2022 +0000 |
| committer | Nan Zhou <nanzhoumails@gmail.com> | Tue Oct 18 17:47:21 2022 +0000 |
| tree | 56cf1d6b7b9c5e99bf783282e30a05f38f2ae3d1 | |
| parent | 307386e8e5a18ec24955fc32bee556409a831a83 [diff] |
use multiple test targets https://gerrit.openbmc.org/c/openbmc/bmcweb/+/57648/8 is unfortunately rejected by some CI issues where # lines covered by unit test is not consistent. Thus, this commit is written to bypass subdir, but still addes the ability to run a test for a specific component. This speeds up iteration when developers are working on a subset of the project. For example, we can compile and run the query_param_test separately. The speed up will be more obvious when we have better solution to deal with the current headers and inline functions in the future. ``` meson test query_param_test -C b ninja: Entering directory `/usr/local/google/home/nanzhou/Desktop/bmcweb/b' ninja: no work to do. 1/1 query_param_test OK 0.01s Ok: 1 Expected Fail: 0 Fail: 0 Unexpected Pass: 0 Skipped: 0 Timeout: 0 ``` The compile time increases a little bit. This doesn't matter too much given tests are disabled in Yocto builds. ``` [hi on] nanzhou@nanzhou:~/Desktop/bmcweb$ time ninja test -C b ninja: Entering directory `b' [49/50] Running all tests. 1/1 bmcweb_unit_test OK 0.07s Ok: 1 Expected Fail: 0 Fail: 0 Unexpected Pass: 0 Skipped: 0 Timeout: 0 Full log written to /usr/local/google/home/nanzhou/Desktop/bmcweb/b/meson-logs/testlog.txt real 1m56.361s user 12m11.587s sys 1m15.924s [hi on] nanzhou@nanzhou:~/Desktop/bmcweb$ time ninja test -C b ninja: Entering directory `b' [247/248] Running all tests. 1/23 crow_getroutes_test OK 0.34s 2/23 router_test OK 0.31s 3/23 utility_test OK 0.29s 4/23 dbus_utility_test OK 0.28s 5/23 google_service_root_test OK 0.27s 6/23 http_utility_test OK 0.26s 7/23 human_sort_test OK 0.24s 8/23 multipart_test OK 0.21s 9/23 openbmc_dbus_rest_test OK 0.20s 10/23 privileges_test OK 0.18s 11/23 registries_test OK 0.17s 12/23 hex_utils_test OK 0.16s 13/23 ip_utils_test OK 0.15s 14/23 json_utils_test OK 0.15s 15/23 query_param_test OK 0.13s 16/23 stl_utils_test OK 0.12s 17/23 chassis_test OK 0.10s 18/23 service_root_test OK 0.04s 19/23 thermal_subsystem_test OK 0.03s 20/23 configfile_test OK 0.23s 21/23 lock_test OK 0.22s 22/23 time_utils_test OK 0.11s 23/23 log_services_dump_test OK 0.07s Ok: 23 Expected Fail: 0 Fail: 0 Unexpected Pass: 0 Skipped: 0 Timeout: 0 Full log written to /usr/local/google/home/nanzhou/Desktop/bmcweb/b/meson-logs/testlog.txt real 2m8.792s user 29m15.844s sys 3m10.264s ``` Signed-off-by: Nan Zhou <nanzhoumails@gmail.com> Change-Id: I6f763173c1e7de96ab757673fb5ed0a73e4532f5
This component attempts to be a "do everything" embedded webserver for OpenBMC.
The webserver implements a few distinct interfaces:
bmcweb at a protocol level supports http and https. TLS is supported through OpenSSL.
Bmcweb supports multiple authentication protocols:
Each of these types of authentication is able to be enabled or disabled both via runtime policy changes (through the relevant Redfish APIs) or via configure time options. All authentication mechanisms supporting username/password are routed to libpam, to allow for customization in authentication implementations.
All authorization in bmcweb is determined at routing time, and per route, and conform to the Redfish PrivilegeRegistry.
*Note: Non-Redfish functions are mapped to the closest equivalent Redfish privilege level.
bmcweb is configured per the meson build files. Available options are documented in meson_options.txt
meson builddir ninja -C builddir
If any of the dependencies are not found on the host system during configuration, meson will automatically download them via its wrap dependencies mentioned in bmcweb/subprojects.
bmcweb by default is compiled with runtime logging disabled, as a performance consideration. To enable it in a standalone build, add the
-Dlogging='enabled'
option to your configure flags. If building within Yocto, add the following to your local.conf.
EXTRA_OEMESON:pn-bmcweb:append = "-Dbmcweb-logging='enabled'"
bmcweb relies on some on-system data for storage of persistent data that is internal to the process. Details on the exact data stored and when it is read/written can seen from the persistent_data namespace.
When SSL support is enabled and a usable certificate is not found, bmcweb will generate a self-signed a certificate before launching the server. Please see the bmcweb source code for details on the parameters this certificate is built with.