summaryrefslogtreecommitdiff
path: root/.azure-pipelines.yml
AgeCommit message (Collapse)AuthorFilesLines
2024-07-05Revert "CI Changes"Tom Rini1-1/+1
This change was brought in by accident, revert. This reverts commit 51aabf50e57f5139de31a4850347edbad8bb338b. Signed-off-by: Tom Rini <trini@konsulko.com>
2024-07-04Merge patch series "xtensa: Enable qemu-xtensa board"Tom Rini1-1/+4
Jiaxun Yang <jiaxun.yang@flygoat.com> says: Hi all, This series enabled qemu-xtensa board. For dc232b CPU it needs to be built with toolchain[1]. This is a side product of me investigating architectures physical address != virtual address in U-Boot. Now we can get it covered under CI and regular tests. VirtIO devices are not working as expected, due to U-Boot's assumption on VA == PA everywhere, I'm going to get this fixed later. My Xtensa knowledge is pretty limited, Xtensa people please feel free to point out if I got anything wrong. Thanks [1]: https://github.com/foss-xtensa/toolchain/releases/download/2020.07/x86_64-2020.07-xtensa-dc232b-elf.tar.gz
2024-07-04CI ChangesJiaxun Yang1-1/+1
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
2024-07-04ci: Wire up qemu_xtensa_dc233cJiaxun Yang1-0/+3
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
2024-07-04CI: Make pytest export JUnitXMLTom Rini1-1/+11
Both GitLab and Azure (and other CI systems) have native support for displaying JUnitXML test report results. The pytest framework that we use can generate these reports. Change our CI tests so that they will generate these reports and then have the respective CI platform pick them up. We write to different locations because of where each CI is (and isn't) able to easily pass things along. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
2024-06-26Azure: Count all of the machines we would buildTom Rini1-0/+28
Now that we have each stage of the world build using variables to define what it will attempt to build, and that we have added in missing machines, add a job to make sure that we would always be building everything. Signed-off-by: Tom Rini <trini@konsulko.com>
2024-06-26Azure: Update some job breakdowns so we build the world againTom Rini1-6/+6
As part of commit 9aeac898da66 ("Azure: Rework build the world jobs") I made a few mistakes. An errant '_' meant that we built neither at91 nor kirkwood platforms. Further, the non-freescale (NXP) "LS1xxx" platforms were also not being built. Adjust some jobs to have these be built again. Fixes: 9aeac898da66 ("Azure: Rework build the world jobs") Signed-off-by: Tom Rini <trini@konsulko.com>
2024-06-26Azure: Spell out the "everything" jobTom Rini1-1/+1
In order to get the list of boards that will be done in a "dry run" build we need to have something listed and not just an exclude list. Populate the job with all architecture directories except arm and powerpc. Signed-off-by: Tom Rini <trini@konsulko.com>
2024-06-26Azure: Rework how we define what to build in the world buildTom Rini1-10/+21
Instead of defining BUILDMAN to the value we'll build in each part of the matrix job, define a variable with that name and have it list what to build. This will allow us to reference these multiple times consistently later on. Signed-off-by: Tom Rini <trini@konsulko.com>
2024-06-26Azure: Correct comment about the strategy in the world matrix buildTom Rini1-2/+2
At this point noting that we have a split in our job similar to TravisCI (which we have not used in years) isn't helpful, and is also not true anymore either. Instead, explain that we split the world up in to 10 jobs as that's the maximum we can have going in parallel on the free tier of Azure. Signed-off-by: Tom Rini <trini@konsulko.com>
2024-03-15CI: Move to latest container imageTom Rini1-1/+1
This moves us to our latest container image, which is now based on the current "Jammy" tag. Signed-off-by: Tom Rini <trini@konsulko.com>
2024-03-14CI: Update to using clang-17Tom Rini1-3/+3
Currently, llvm-17 is the stable release. Update our container and CI to fetch and use that. Signed-off-by: Tom Rini <trini@konsulko.com>
2024-03-11Merge tag 'v2024.04-rc4' into nextTom Rini1-5/+4
Prepare v2024.04-rc4
2024-02-29CI: Exclude devicetree-rebasing subtree for CONFIG checksSumit Garg1-1/+2
Since devicetree-rebasing is an external repo with its own coding style, exclude it from Azure and gitlab CI CONFIG checks. Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
2024-02-27CI: Move to latest container imageTom Rini1-1/+1
This moves us to our latest container image, which is now based on the current "Jammy" tag. Signed-off-by: Tom Rini <trini@konsulko.com>
2024-02-27CI: Switch to using coreboot from our imageTom Rini1-4/+3
Instead of downloading coreboot binaries from a Google drive location, use the ones we have built ourselves. Signed-off-by: Tom Rini <trini@konsulko.com>
2024-01-18CI: Move to latest Ubuntu "Jammy" tagTom Rini1-1/+1
Move to the latest "Jammy" tag from Ubuntu. Signed-off-by: Tom Rini <trini@konsulko.com>
2023-11-07CI, pytest: Add a test for sandbox without LTOTom Rini1-3/+0
The primary motivation for having a sandbox without LTO build in CI is to ensure that we don't have that option break. We now have the ability to run tests of specific options being enabled/disabled, so drop the parts of CI that build and test that configuration specifically and add a build test instead. We still test that "NO_LTO=1" rather than editing the config file works via the ftrace tests. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
2023-11-02CI: use OpenSBI 1.3.1 for testingHeinrich Schuchardt1-4/+4
Use the most recent upstream release of OpenSBI for CI testing. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
2023-10-23CI: Re-enable maintainer checkTom Rini1-1/+1
At this point we have all of the defconfigs maintained again, so re-enable the check to prevent further regressions. Signed-off-by: Tom Rini <trini@konsulko.com>
2023-10-17test: spl: Add functions to create imagesSean Anderson1-0/+4
This add some basic functions to create images, and a test for said functions. This is not intended to be a test of the image parsing functions, but rather a framework for creating minimal images for testing load methods. That said, it does do an OK job at finding bugs in the image parsing directly. Since we have two methods for loading/parsing FIT images, add LOAD_FIT_FULL as a separate CI run. Signed-off-by: Sean Anderson <seanga2@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2023-10-02Merge branch 'next'Tom Rini1-212/+172
Signed-off-by: Tom Rini <trini@konsulko.com>
2023-09-06Azure: Add sandbox64 to CITom Rini1-0/+5
Now that sandbox64 can run and pass the regular test.py suite, add it here as well. Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2023-09-06Azure: Split sandbox and qemu test.py runsTom Rini1-17/+44
Currently, most sandbox runs take a long time (due to running so many tests) while QEMu based test.py runs are fairly short. Split the pipeline here so that we get more consistent average run times. Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2023-09-06Azure: Rework test_py job to publish its wrapper scriptTom Rini1-71/+90
Both to aide in debugging of any test.py issues as well as to make it easier to split the current matrix in two, have a new job that creates and publishes the current wrapper script we use for test.py jobs. Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2023-09-06CI: Drop some jobs we didn't really utilizeTom Rini1-32/+0
- We have added more TODO/etc comments since this task was created and never focused on removing them. - The output of sloccount isn't preserved or looked at, and if desired should be in the release stats pages instead somehow. - The results of cppcheck aren't investigated and require modeling work to be useful to start with. Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2023-09-06CI: Combine tools-only and envtools jobsTom Rini1-11/+2
These jobs are to confirm specific build targets, on a Linux host. We can safely combine these two build tests, with a make mrproper in between. Signed-off-by: Tom Rini <trini@konsulko.com>
2023-09-06Azure: Rework build the world jobsTom Rini1-75/+25
Now that we have 3600 minutes per build job, condense and rework things such that our overall time largely doesn't change, but we can also largely avoid having to re-tweak this job to avoid timeouts. Given that we have 10 threads, we also move a few of the specific sandbox test builds to a prior stage. Note that while sandbox builds with address sanitization enabled (ASAN) not all tests pass, so we limit ourselves to just checking that the version test passes for now. Link: https://learn.microsoft.com/en-us/azure/devops/pipelines/process/phases?view=azure-devops&tabs=yaml#timeouts Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2023-09-04nokia_rx51: Remove platformTom Rini1-19/+0
This platform is behind on migrations (it is the sole user of the oldest legacy version of the USB gadget stack and is long overdue for migration) and with Pali no longer being a maintainer, we remove this platform. Signed-off-by: Tom Rini <trini@konsulko.com>
2023-09-04Merge tag 'v2023.10-rc4' into nextTom Rini1-0/+1
Prepare v2023.10-rc4
2023-08-29sandbox: trace: Increase trace buffer sizeSughosh Ganu1-1/+1
When running the trace test on the sandbox platform, the current size of 16MiB is no longer large enough for capturing the entire trace history, and results in truncation. Use a size of 32MiB for the trace buffer on the sandbox platform while running the trace test. Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org>
2023-08-28Azure: Set the timeout for jobs to the maximumTom Rini1-0/+1
As per current Azure Pipelines documentation we qualify for 3600 minutes per job, if specified, as the timeout. The default unspecified timeout is 60 minutes. Rework things to specify 0 as the timeout (and so maximum allowed) so that we don't have failures due to running slightly past 60 minutes total. Link: https://learn.microsoft.com/en-us/azure/devops/pipelines/process/phases?view=azure-devops&tabs=yaml#timeouts Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2023-08-26CI: Move to latest Ubuntu "Jammy" tagTom Rini1-1/+1
Move to the latest "Jammy" tag from Ubuntu. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
2023-08-26CI: Update to gcc-13.2.0Tom Rini1-1/+1
The latest kernel.org toolchains for gcc are now 13.2.0, so upgrade to that. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
2023-08-21Merge tag 'v2023.10-rc3' into nextTom Rini1-1/+1
Prepare v2023.10-rc3 Signed-off-by: Tom Rini <trini@konsulko.com>
2023-08-17CI: Switch to tools-only from sandbox_spl for tooling testsTom Rini1-4/+4
When running tools for various tests use the tools-only build rather than sandbox_spl. We used sandbox_spl here for historical reasons that are no longer true. Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2023-08-17CI: x86: coreboot: Update to latest corebootSimon Glass1-1/+1
Use a recent coreboot build for this test. The coreboot commit is: 6f5ead14b4 mb/google/nissa/var/joxer: Update eMMC DLL settings This is build with default settings, i.e. QEMU x86 i440fx/piix4 Add some documentation as to how to update it next time. Signed-off-by: Simon Glass <sjg@chromium.org>
2023-08-07Azure: Squash a number of jobs and re-order slightlyTom Rini1-49/+23
To reduce overall job time, move a number of smaller jobs together. These should still be safely under 1 hour total time, but reducing the overall number of jobs should help with the queue slightly. Signed-off-by: Tom Rini <trini@konsulko.com>
2023-08-07Azure: Rework Rockchip jobs againTom Rini1-5/+5
The job for rockchip vendor platforms has again gotten close to or exceeded one hour. Rework things such that we move the 32bit platforms back to the general 32bit ARM job (as there's time there) and make these build only the 64bit platforms. Signed-off-by: Tom Rini <trini@konsulko.com>
2023-07-24buildman: Add an option to check maintainersSimon Glass1-1/+1
Rather than using the -R option to get this report as a side effect, add a dedicated option for it. Disable CI for now as there are some missing maintainers, unfortunately. Signed-off-by: Simon Glass <sjg@chromium.org>
2023-07-21CI: Make use of buildman requirements.txtTom Rini1-0/+4
Now that buildman has a requirements.txt file we need to make use of it. Reviewed-by: Simon Glass <sjg@chromium.org> [n-francis@ti.com: Adding missing command from .azure-pipelines.yml] Signed-off-by: Neha Malcom Francis <n-francis@ti.com> Signed-off-by: Tom Rini <trini@konsulko.com>
2023-07-20CI: Add automatic retry for test.py jobsTom Rini1-0/+1
It is not uncommon for some of the QEMU-based jobs to fail not because of a code issue but rather because of a timing issue or similar problem that is out of our control. Make use of the keywords that Azure and GitLab provide so that we will automatically re-run these when they fail 2 times. If they fail that often it is likely we have found a real issue to investigate. Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2023-07-20Azure: Add excludes to the imx8_imx9 jobTom Rini1-1/+1
The job to build all imx8 and imx9 platforms is currently close to, or sometimes exceeding the allowed build time. Exclude some platforms that are already being built under their vendor-specific job as well to reduce the time. Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2023-07-20Azure: Rework our Rockchip jobs slightlyTom Rini1-4/+4
Currently the 64bit "rk" job is close to and sometimes goes over the job time limit. Let us rework this in to one job for "rk" and "rv" (which are the SoC prefixes) jobs which include or exclude "rockchip" the board vendor. This gives us two jobs of similar numbers of platforms to build now instead. Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2023-07-20CI: Update to the latest "Jammy" tagTom Rini1-1/+1
Move to the latest "Jammy" tag from Ubuntu. Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2023-07-20CI: Update to gcc-13.1.0Tom Rini1-1/+1
As this is the current version of the public cross toolchains we use, upgrade to this now. Suggested-by: Alexey Brodkin <Alexey.Brodkin@synopsys.com> Signed-off-by: Tom Rini <trini@konsulko.com> Acked-by: Alexey Brodkin <abrodkin@synopsys.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2023-07-06ci: riscv: Update OpenSBI to v1.2Bin Meng1-4/+4
Use the latest OpenSBI v1.2 release binaries for the RISC-V CI. Signed-off-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
2023-06-29CI: Azure: Split keymile jobs outTom Rini1-2/+4
Currently the PowerPC build job in Azure will hit the maximum time limit for a build and stop. Looking at the job, the easiest path to reducing it is to move Keymile vendor boards to their own job and exclude them from the PowerPC one (and while at this, the ls102 job). Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Heiko Schocher <hs@denx.de>
2023-05-04CI: treat documentation warnings as errorsHeinrich Schuchardt1-1/+1
We do not want to merge documentation that produces Sphinx warnings. scripts/kernel-doc uses environment variable KDOC_WERROR to determine if warnings should be treated as errors. Reported-by: Tom Rini <trini@konsulko.com> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2023-04-15CI: Add m68k targetMarek Vasut1-0/+5
Add M5208EVBE board to CI. This does not use default config due to limitations of QEMU emulation, instead the timer is switched from DMA timer to PIT timer and RAMBAR accesses are inhibited. Local QEMU launch command is as follows: $ qemu-system-m68k -nographic -machine mcf5208evb -cpu m5208 -bios u-boot.bin Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Acked-by: Angelo Dureghello <angelo@kernel-space.org>