With the addition of the clang tests, the jenkins builds are taking a
really long time to run the tests. This change allows the
"what-jenkins-does" build to be split into separate builds on jenkins.
Additionally, some jenkins builds like coverity don't need (or want)
to build clang or even the linters.
Update help with the variables.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I0f8ac68c1bc8f8ff9be62d80db850355e742ee74
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69495
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This tests building a single target with scanbuild so to make sure that
option hasn't been broken. Since it's a different type of build, it
hasn't previously been tested with what-jenkins-does.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I8a74dac203f4d38c0cb30a0b64724e6f9095b9dd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69861
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This gets rid of the duplicated directory and xml filename and uses the
--name argument to abuild instead, which also updates the test name in
the junit xml file.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ibe538da42280696190b0a7a0c63fd86a63e40214
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69860
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Instead of having duplicate lines in the what-jenkins-does target and
the test-tools target, make test-tools from what-jenkins-does.
Now there's only one place to update when changing the call.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Id62d6bb1e729892ec123ea970ca8a31e03a812d0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69838
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Instead of having duplicate lines in the what-jenkins-does target and
the test-abuild target, make test-abuild from what-jenkins-does.
The test-abuild target had not been updated to use the ABUILD_OPTIONS
variable, so update it with the commands from what-jenkins-does.
Now there's only one place to update when changing the call.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I4552193894c16301defb851eb3db4bdfbfa49803
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69836
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Instead of having duplicate lines in the what-jenkins-does target and
the test-lint target, make test-lint with the --junit argument from
what-jenkins-does.
Now there's only one place to update when changing the call.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I2f90df76126f453fbcd91f4c4af5d784ac2dbe88
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69835
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Instead of having the what-jenkins-does target clean up before building,
have it call the test_cleanup target.
Clean the tegra targets.
Remove distclean from test_cleanup target - I don't think that's
expected, and people might be upset by having their .config deleted.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ia9d585df05343365c89e49b1c01dba9ba865003f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69834
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This patch introduces new target: junit.xml-unit-tests, which builds and
runs unit-tests. It also creates build log containing build logs. This
feature allows for one to see build failures in Jenkins dashboard.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: I94184379dcc2ac10f1a47f4a9d205cacbeb640fe
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67372
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Firmware is typically delivered as one large binary image that gets
flashed. Since this final image consists of binaries and data from
a vast number of different people and companies, it's hard to
determine what all the small parts included in it are. The goal of
the software bill of materials (SBOM) is to take a firmware image
and make it easy to find out what it consists of and where those
pieces came from. Basically, this answers the question, who supplied
the code that's running on my system right now? For example, buyers
of a system can use an SBOM to perform an automated vulnerability
check or license analysis, both of which can be used to evaluate
risk in a product. Furthermore, one can quickly check to see if the
firmware is subject to a new vulnerability included in one of the
software parts (with the specified version) of the firmware.
Further reference:
https://web.archive.org/web/20220310104905/https://blogs.gnome.org/hughsie/2022/03/10/firmware-software-bill-of-materials/
- Add Makefile.inc to generate and build coswid tags
- Add templates for most payloads, coreboot, intel-microcode,
amd-microcode. intel FSP-S/M/T, EC, BIOS_ACM, SINIT_ACM,
intel ME and compiler (gcc,clang,other)
- Add Kconfig entries to optionally supply a path to CoSWID tags
instead of using the default CoSWID tags
- Add CBFS entry called SBOM to each build via Makefile.inc
- Add goswid utility tool to generate SBOM data
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: Icb7481d4903f95d200eddbfed7728fbec51819d0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/63639
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Amdfwtool creates AMD firmware images however there is currently no way
to get information from an existing image. This commit adds amdfwread to
support that functionality. At the moment only reading PSP soft fuse
flags is supported. Example usage: `amdfwread --soft-fuse bios.bin`,
example output: `Soft-fuse:0x400000030000041`.
BUG=b:202397678
TEST=Ran amdfwread and verified that it correctly reads the soft fuse
bits, verified that built AMD FW still boots on DUT
Signed-off-by: Robert Zieba <robertzieba@google.com>
Change-Id: I15fa07c9cad8e4640e9c40e5539b0dab44424850
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62795
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
As part of the `what-jenkins-does` target, combine the code coverage
data from all unit tests (currently just coreboot and libpayload).
BUG=b:203800199
TEST=`make what-jenkins-does && ls -l coreboot-builds/coverage.info`
Signed-off-by: Paul Fagerburg <pfagerburg@google.com>
Change-Id: Id99615ca8279f80a402d5371221b8fd36fb91d55
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59959
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <patrick@coreboot.org>
Without manual handling, when 3rdparty/intel-sec-tools isn't around,
`make what-jenkins-does` reports only
go: go.mod file not found in current directory or any parent directory; see 'go help modules'
which isn't meaningful or actionable. Instead check that the go.mod file
exists and bail out with a better error message before trying to run
`go mod vendor`.
Change-Id: I035747746ca5fd54841bd67352044dde12a28185
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/57527
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Add COV=1 and the `coverage-report` target to unit test build rules
in `what-jenkins-does` so that we get code coverage data from the
coreboot and libpayload unit tests.
Signed-off-by: Paul Fagerburg <pfagerburg@google.com>
Change-Id: I96669c47d1a48e9ab678a4b9cb1d0c8032d727f0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58634
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
coreboot test targets help section was missing an empty line at the end.
This caused the next help section to be visually merged with it.
Empty line makes help output more aesthetic.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: I2f7202b0a636f62b60788215058611c9c86183de
Reviewed-on: https://review.coreboot.org/c/coreboot/+/54367
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
This file was being written to the root src directory. It is the only
file being written to src during a normal build, while all others are
being written to $(obj). I added a new variable to allow specifying the
xcompile path. This allows generating a single file if building multiple
boards. I also moved the default location into $(obj) so we don't
pollute the src directory by default.
I also cleaned up the generation of xcompile by removing the unnecessary
eval and NOCOMPILE check.
I also left .xcompile in distclean so it cleans up stale files.
Since .xcompile is written into $(obj), `make clean` will now remove it.
The tegra Makefiles are outside of the normal build process, so I just
updated those Makefiles to point to the default xcompile location of a
normal build. The what-jenkins-does target had to be updated to support
these special targets. We generate an xcompile specifically for these
targets and pass it into the Makefile. Ideally we should get these
targets added to the main build.
BUG=b:112267918
TEST=ran `emerge-grunt coreboot` and `make what-jenkins-does`
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ia83f234447b977efa824751c9674154b77d606b0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/28101
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The linters touch every file under src and probably util. This makes
it difficult to see what files have been accessed by the builder.
The JENKINS_SKIP_LINT_TESTS variable will only be set on the jenkins
build that looks for unused files.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I12fa31641c2a72c5e07be1c4958467f7165f21bb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46807
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Stefan thinks they don't add value.
Command used:
sed -i -e '/file is part of /d' $(git grep "file is part of " |egrep ":( */\*.*\*/\$|#|;#|-- | *\* )" | cut -d: -f1 |grep -v crossgcc |grep -v gcov | grep -v /elf.h |grep -v nvramtool)
The exceptions are for:
- crossgcc (patch file)
- gcov (imported from gcc)
- elf.h (imported from GNU's libc)
- nvramtool (more complicated header)
The removed lines are:
- fmt.Fprintln(f, "/* This file is part of the coreboot project. */")
-# This file is part of a set of unofficial pre-commit hooks available
-/* This file is part of coreboot */
-# This file is part of msrtool.
-/* This file is part of msrtool. */
- * This file is part of ncurses, designed to be appended after curses.h.in
-/* This file is part of pgtblgen. */
- * This file is part of the coreboot project.
- /* This file is part of the coreboot project. */
-# This file is part of the coreboot project.
-# This file is part of the coreboot project.
-## This file is part of the coreboot project.
--- This file is part of the coreboot project.
-/* This file is part of the coreboot project */
-/* This file is part of the coreboot project. */
-;## This file is part of the coreboot project.
-# This file is part of the coreboot project. It originated in the
- * This file is part of the coreinfo project.
-## This file is part of the coreinfo project.
- * This file is part of the depthcharge project.
-/* This file is part of the depthcharge project. */
-/* This file is part of the ectool project. */
- * This file is part of the GNU C Library.
- * This file is part of the libpayload project.
-## This file is part of the libpayload project.
-/* This file is part of the Linux kernel. */
-## This file is part of the superiotool project.
-/* This file is part of the superiotool project */
-/* This file is part of uio_usbdebug */
Change-Id: I82d872b3b337388c93d5f5bf704e9ee9e53ab3a9
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41194
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reduces disk usage during builds by removing all object files and
other intermediate files directly after a build instead of waiting for
the entire build to pass.
Change-Id: Ic2feecd58658e8bac8c6e7a851737784e35b83ef
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35112
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The JUnit output from the libpayload builds was getting deleted by the
coreinfo build. Move the libpayload to later in the coreboot-gerrit
job.
Also add messages to stdout indicating the various libpayload configs
that are built and a message indicating when all libpayload builds are
complete.
BUG=b:137380189
TEST=Upload test commit that includes a libpayload compile error and
verify buildbot fails.
Change-Id: I43b55f402216582dcf81be34171437be345572ab
Signed-off-by: Keith Short <keithshort@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34183
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The reason for this code cleanup is the legacy
Google Purin board which isn't available anymore
and AFAIK never made it into the stores.
* Remove broadcom cygnus SoC support
* Remove /util/broadcom tool
* Remove Google Purin mainboard
* Remove MAINTAINERS entries
Change-Id: I148dd7eb0192d396cb69bc26c4062f88a764771a
Signed-off-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/29905
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add a `util/gitconfig/test` subdirectory which will contain tests to run
as executable files, add a helper script.
Add a timeout test that verifies that gitconfig completes in under two
seconds (typical run time is ~30 ms). Add gitconfig tests to the
`testing` Makefile under the `test-tools` target.
Change-Id: Id46f905b9f782e67be97a65d10045c3345dc996b
Signed-off-by: Alex Thiessen <alex.thiessen.de+coreboot@gmail.com>
Reviewed-on: https://review.coreboot.org/23280
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Even though we were setting V=1 in the build, this wasn't getting passed
to abuild, so the builds there didn't have additional debug information.
That made it difficult to debug issues on the builder. This sets the
verbose flag for abuild if V=1 is set.
Change-Id: Id9ec50add9693a6c36ffdb5c78d148d0fc012549
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/27492
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Because the tegra124 & tegra201 lp0 builds weren't junit tests, the
builds weren't actually picked up by jenkins, so any failures were
not previously reported.
Change-Id: Ie443ca713912d01ccf6921ce49f846d7297163ef
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/26422
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Up to this point, junit.xml has only been used to build tools, as abuild
has handled the coreboot builds. To add additional tests not covered
by abuild, we need junit.xml to work with bare directories.
This also requires updating the build directory (BLD_DIR) for existing
builds using the junit.xml target.
Change-Id: If6e27e02e25e20f48e5a9372373de6058ca378dd
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/26421
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
