Lines Matching +full:docker +full:- +full:test +full:- +full:clang

11 - Binaries and static files should take up < 1MB of filesystem size
12 - Memory usage should remain below 10MB at all times
13 - Application startup time should be less than 1 second on target hardware
29 - All buffer boundaries must be checked before indexing or using values
30 - All pointers and iterators must be checked for null before dereferencing
31 - All input from outside the application is considered untrusted, and should be
34 - All error statuses are checked and accounted for in control flow.
35 - Where applicable, noexcept methods should be preferred to methods that use
37 - Explicitly bounded types should be preferred over implicitly bounded types
39 - no use of
40 …[Banned functions](https://github.com/intel/safestringlib/wiki/SDL-List-of-Banned-Functions "Banne…
47 - 200 OK - Request was properly handled
48 - 201 Created - Resource was created
49 - 401 Unauthorized - Request didn't posses the necessary authentication
50 - 403 Forbidden - Request was authenticated, but did not have the necessary
52 - 404 Not found - The url was not found
53 - 500 Internal error - Something has broken within the OpenBMC web server, and
64 - Minimizing the number of files read from disk at startup. Unless a feature is
69 - Avoid excessive memory usage and mallocs at startup.
73 - At this point in time, the webserver sets a number of security flags in
77 - Exceptions are currently enabled for webserver builds, but their use is
83 - Run time type information is disabled
84 - Link time optimization is enabled
90 - Basic authentication
91 - Cookie authentication
92 - Token authentication
124 ### webui-vue
126 The webserver should be capable of hosting webui-vue, and implementing the
148 [link](https://github.com/openbmc/docs/blob/master/CONTRIBUTING.md#formatting-commit-messages)
152 - Why are the changes useful? Given that bmcweb is a user-facing daemon, commits
156 - What changes would a user expect to see? This includes new parameters, new
160 - Are there compatibility concerns? Is this change backward compatible for
168 > Don't make your users mad -
169 > [Greg K-H](https://git.sr.ht/~gregkh/presentation-application_summit/tree/main/keep_users_happy.p…
182 - New items added to a collection
183 - Changes in UID for hypermedia resources (In line with Redfish spec)
184 - New properties added to a resource
185 - New versions of a given schema
188 function. Given that compatibility requires the ability to use and test the
199 ### clang-tidy
201 clang-tidy is a tool that can be used to identify coding style violations, bad
203 .clang-tidy file in the root of bmcweb, and are expected to be passing.
204 [openbmc-build-scripts](https://github.com/openbmc/openbmc-build-scripts/blob/master/run-unit-test-…
205 implements clang-tidy checks and is the recommended way to run these checks
211 - debug
212 - info
213 - warning
214 - error
215 - critical
219 - critical: Something went badly wrong, and we're no longer able to serve
223 - error: Something went wrong, and we weren't able to give the expected
227 - warning: A condition occurred that is outside the expected flows, but isn't
230 - info: Information for the golden path debugging.
231 - debug: Information that's overly verbose such that it shouldn't be printed in
240 -Dlogging='debug'
247 EXTRA_OEMESON:pn-bmcweb:append = "-Dbmcweb-logging='debug'"